관리 백엔드에서 계정 시스템을 정렬하는 네 가지 방법

회사가 성장함에 따라 내부 IT 시스템, OA 시스템, 비즈니스 시스템뿐만 아니라 다양한 로그인 프로세스는 물론 외부 제품과 통합된 많은 로그인 프로세스까지 직원이 사용해야 하는 제품 매트릭스가 점점 더 풍부해질 것입니다. 비즈니스 시스템 또는 하위 시스템의 계정 시스템입니다. 단순하고 투박한 방법을 사용하여 직원이 각 시스템에 독립적인 계정을 등록할 수 있게 하면 직원의 사용자 경험이 단순하고 투박해질 뿐만 아니라 직원 비밀번호 관리와 관련된 비용도 갑자기 증가하게 됩니다.

이 글을 시작하기 전에 먼저 계정 시스템 인증이 무엇인지에 대해 말씀드리고 싶습니다.

계정 시스템 인증이란 무엇입니까?

어떤 제품을 사용하든 계정에 로그인하려면 휴대폰 번호, 사용자 이름, 이메일 또는 회사 번호를 입력하여 제품에 로그인해야 할 수 있습니다. (QR 코드를 스캔하는 것은 실제로 다른 방법입니다.) 그런데 왜 이 과정에서 우리 자신의 관련 정보를 입력해야 할까요?

실제로 이 과정에서 우리는 주로 다음 세 가지 문제를 해결합니다 .

이 세 가지 질문은 계정 시스템의 신원 인증 및 권한 부여의 기본 요소를 구성하기 때문에 매우 중요합니다. 먼저 다음 세 가지 질문에 각각 대답해 보겠습니다.

1. 나는 누구인가?

이 질문은 사용자나 시스템의 신원에 관한 것입니다. 서버측 계정 시스템에서는 각 사용자나 시스템에 고유 식별자(일반적으로 사용자 이름, 이메일 주소, 사용자 ID 또는 기타 고유 정보)가 있는지 확인해야 합니다. 이 식별자는 다양한 엔터티를 식별하고 구별하는 데 사용됩니다. 인증의 첫 번째 단계는 식별자가 유효한지 확인하고 식별자에 해당하는 사용자나 시스템을 식별하는 것입니다.

2. 나에게는 어떤 권한이 있나요?

이 질문에는 사용자나 시스템에 부여된 작업 또는 리소스 액세스 권한이 포함됩니다. 권한은 읽기 전용 권한부터 전체 제어 권한까지 여러 수준으로 나눌 수 있습니다. 서버 측 계정 시스템에서는 일반적으로 역할 또는 권한 그룹을 사용하여 권한을 관리합니다. 사용자나 시스템은 하나 이상의 역할이나 그룹에 할당되며, 각 역할이나 그룹은 특정 권한 집합을 정의합니다. 인증 후 사용자 또는 시스템이 액세스할 수 있는 리소스와 수행할 수 있는 작업이 해당 역할 또는 그룹에 따라 결정되는지 확인하십시오.

3. 나는 어떤 조직에 속해 있나요?

이 질문은 사용자 또는 시스템의 조직 소속에 중점을 둡니다. 많은 애플리케이션에서 사용자는 회사, 팀, 부서 등 하나 이상의 조직에 속할 수 있습니다. 조직은 일반적으로 리소스 액세스 및 공유를 관리하고 조직 내 사용자의 역할과 권한을 결정하는 데 사용됩니다. 리소스 액세스가 적절하게 승인되고 제한되도록 계정 아키텍처가 여러 조직과 해당 조직 간의 사용자 관계를 처리할 수 있는지 확인하십시오.

관리 백엔드에서 계정 시스템을 어떻게 정렬합니까?

계정 시스템을 처리하는 우리의 주요 임무는 시스템의 계정, 역할 권한, 조직 및 기타 정보가 신원 인증 및 권한 부여 기능을 달성하기 위해 통합되어야 하는 시스템의 관련 필드와 함께 작동할 수 있도록 하는 것입니다. 업계에는 이미 다음과 같은 매우 전문적인 문제 해결 아이디어가 있습니다.

1. 싱글 사인온 SSO

SSO는 사용자가 여러 시스템에서 단일 인증 자격 증명을 사용하여 로그인할 수 있도록 하는 일반적인 솔루션입니다 . 표준 프로토콜(예: OAuth, SAML, OpenID Connect 등)을 사용하여 계정 시스템을 통합해야 하는 시스템에 연결할 수 있습니다. 일단 연결되면 사용자가 한 시스템에 로그인하면 다시 로그인할 필요 없이 다른 시스템에 액세스할 수 있습니다.

2. API 통합

또한 사용자, 역할, 권한, 조직 등 관련 정보를 관리하기 위한 API 세트를 설계 할 수도 있습니다 . 이러한 API를 사용하여 사용자 계정을 생성, 업데이트, 삭제하고, 역할을 할당하고, 권한을 할당하고, 조직 구조를 관리할 수 있습니다. 다른 시스템은 이러한 API를 호출하여 계정 시스템과 상호 운용할 수 있습니다.

3. 데이터 동기화 매핑

일부 특수 시스템에는 현재 비즈니스에 필요한 일부 비즈니스 분야가 있을 수 있으므로 데이터 동기화 및 필드 매핑을 사용하여 서로 다른 시스템 간의 일관성을 유지할 수 있는 방법도 고려해야 합니다 . 사용자, 역할, 권한, 조직 등의 데이터를 정기적으로 동기화하여 시스템 전체에서 일관되게 유지하세요. 물론, 데이터 동기화의 전제 조건은 서로 다른 시스템의 데이터가 올바르게 일치할 수 있도록 필드 매핑 규칙을 정의해야 한다는 것입니다.

4. 중앙화된 인사관리

가능하다면 모든 사용자, 역할, 권한을 관리하는 중앙 집중식 ID 관리 시스템을 구축해 볼 수도 있습니다. 다른 시스템을 이 중앙 시스템과 통합하여 신원 정보를 중앙에서 관리할 수 있습니다 . 이 접근 방식은 데이터 불일치 문제를 줄이고 유지 관리를 단순화합니다.

물론 최종적으로 어떤 계정 시스템 정렬 방법을 선택하든, 가능한 후속 감사 및 로그 보존 기능에 대처하기 위해 자체 비즈니스 시스템과 통합하는 것 외에도 충분한 코드 및 비즈니스 감사 메커니즘을 제공하는 것을 고려해야 합니다. 이상현상이나 비인가 접근에 대해서는 해당 사항을 확인하시기 바랍니다.

FinClip의 관리자 계정 정렬

위에서 언급한 바와 같이 당사는 일부 고객에게 관련 서비스를 제공할 때 계정 시스템 정렬을 해결하기 위해 "데이터 동기화" 또는 "실시간 확인"을 사용합니다. 물론 고객마다 비즈니스 환경과 내부 비즈니스 수준이 다르기 때문에 두 가지 방법의 장점과 고려해야 할 관련 위험도 정리했습니다.

해결 방법 1: 데이터 동기화

이 방법을 이용하려면 고객은 해당 계정 정보를 핀클립이 제공하는 OpenAPI 및 관련 서비스를 기반으로 우리가 제공하는 서비스와 동기화하고, 최종적으로 통합 계정 시스템을 통해 계정 인증 및 로그인 작업을 완료해야 합니다 .

이 접근 방식에는 다음과 같은 장점이 있습니다 .

더 나은 성능 및 시간 이점: 데이터가 FinClip 서비스에 동기화되어 실제 사용과 쿼리에 소요되는 시간이 줄어들고 효율성이 높아졌습니다.
오프라인 지원: 데이터가 FinClip 서비스에 동기화되었습니다. 고객의 계정 도킹 시스템에 장애가 발생하더라도 최종 사용자는 계속 작업 및 액세스 요청을 완료할 수 있습니다.
통합업체의 부담을 줄입니다. 고객은 정기적으로 데이터를 동기화하기만 하면 되며 더 이상 실시간 요청을 고려할 필요가 없습니다.

물론 이 접근 방식을 채택할 때는 다음과 같은 위험도 고려해야 합니다 .

데이터 동기화가 지연될 수 있습니다. 데이터 동기화가 지연될 수 있으며 경우에 따라 최신 계정 정보가 즉시 반영되지 않을 수 있습니다.
데이터 일관성을 보장하려면 정기적인 동기화가 필요합니다. 일관성을 보장하려면 데이터를 정기적으로 동기화하고 업데이트해야 하지만 일부 동기화 문제가 발생할 수 있습니다.
가능한 보안 위험: 데이터 동기화 중에 계정 정보가 위험할 수 있으므로 데이터 기밀성과 무결성이 보장되어야 합니다.

옵션 2: 실시간 확인

이 방법을 이용하려면 핀클립이 고객이 제공하는 계정 인터페이스를 통해 계정 확인 작업을 완료하고, 계정 관련 정보를 획득한 후 로그인을 완료해야 합니다.

이 접근 방식에는 다음과 같은 장점이 있습니다 .

높은 실시간 성능: FinClip은 언제든지 최신 계정 정보를 요청할 수 있어 높은 실시간 성능을 보장합니다.
정확한 제어: 특정 비즈니스에서는 전체 데이터 내용을 동기화하는 대신 계정의 관련 정보를 정확하게 요청하고 얻을 수 있습니다.
데이터 중복성 감소: FinClip은 더 이상 관련 현장 데이터를 계정에 별도로 저장할 필요가 없으므로 데이터 중복성 및 일관성과 관련된 문제가 줄어듭니다.

물론 이 방법을 선택할 때 이러한 위험도 고려해야 합니다 .

불확실한 성능 및 응답 시간: 실시간 검증은 특히 부하가 높거나 통합업체 시스템이 느리게 응답할 때 지연을 일으킬 수 있습니다.
고객 통합 시스템에 대한 높은 의존도: 서비스는 통합업체의 안정성과 성능에 크게 의존하며, 통합업체가 실패하거나 지연될 경우 FinClip의 서비스 및 관련 기능에 영향을 미칠 수 있습니다.
빈번한 통화가 필요할 수 있습니다. 계정 정보에 자주 액세스해야 하는 경우 요청이 너무 많아지고 통합업체의 부담이 커질 수 있습니다.

전반적으로 접근 방식의 선택은 고객 자체 비즈니스 또는 IT 시스템의 요구 사항과 시스템 아키텍처에 따라 달라집니다. 실시간 요구 사항이 높은 경우 "옵션 1, 실시간 확인"을 고려할 수 있습니다. 성능과 가용성이 더 중요하거나 대량의 데이터를 처리해야 하는 경우 "옵션 2, 데이터 동기화"가 더 적합할 수 있습니다.

물론 실제 경험에서 우리는 일부 고객이 도킹을 위해 표준 프로토콜을 선택하지 않고 대신 자신의 비즈니스 시나리오 및 기능을 기반으로 일련의 "비표준 계정 프로토콜"을 캡슐화했다는 사실도 발견했습니다. 그러나 표준 프로토콜을 선택하든 비표준 프로토콜을 선택하든 관계없이 여기서 도킹 아이디어는 비슷합니다.

표준 프로토콜 도킹:

고유 식별자 가져오기 accountID (OAuth/SAML/OIDC 도킹 기반)
사용자 로그인 : 표준 프로토콜에 따라 사용자 본인 확인 후 로그인
사용자 역할: 사전 구성된 구성을 기반으로 사용자 역할을 획득하고 사용자가 직접 수정할 수 있으며 계정 통합 시스템에는 역할 관리 기능이 제공됩니다.

비표준 프로토콜 도킹:

token/Account/Customer API를 통해 미리 인터페이스를 생성해 보세요.
사용자 로그인 : 해당 매개변수에 따라 사용자 본인 확인 후 로그인
사용자 역할: 사전 구성된 구성을 기반으로 사용자 역할을 획득하고 사용자가 직접 수정할 수 있으며 계정 통합 시스템에는 역할 관리 기능이 제공됩니다.

일반적으로 실제 적용에서는 두 가지 방법의 장단점을 종합적으로 고려하거나 다양한 사용 사례에 따라 서로 다른 통합 방법을 선택할 수 있습니다. 가장 중요한 것은 데이터 일관성, 보안 및 가용성을 보장하는 것입니다.

핀클립의 미니 프로그램 계정 정렬

관리 백엔드의 계정 정렬 방법에 대해 이야기한 후에 "미니 프로그램 비즈니스"에서 사용자 계정 정렬의 일반적인 문제에 대해 이야기하는 것이 좋습니다.

미니 프로그램은 대부분 호스트 앱(또는 기기)에 기능 모듈로 존재하기 때문에 미니 프로그램의 로그인 방법은 일반적으로 호스트 앱(또는 기기)의 계정을 기반으로 수정되며 미니 프로그램에서는 수정되지 않습니다. 앱과 동일한 로그인 페이지가 다시 나타납니다.

우리에게 익숙한 WeChat 미니 프로그램에서는 일반적으로 미니 프로그램 측에서 사용자 코드를 호출한 후 서버 측 검증을 통해 호출합니다. wx.login

FinClip 시나리오에서는 다양한 유형의 개발자가 선택할 수 있는 풍부하고 유연한 사용자 인증 방법도 제공하며, 어떤 유형의 개발자라도 FinClip을 기반으로 유연한 미니 프로그램 계정 정렬 기능을 얻을 수 있습니다.

옵션 1: 서버 측 변환

서버측 수정의 사용 시나리오는 주로 "고객이 핀클립을 기반으로 자신만의 미니 프로그램 생태계를 만들지만, 미니 프로그램의 코드를 제어할 수 있는 능력이 없습니다." 이 경우에는 서버측을 사용하는 것이 더 적합합니다. 가감.

이 경우 고객은 다음 링크에서 관련 수정 비용을 투자해야 합니다.

1단계: 앱에 사용자 정의 API를 통해 메소드를 삽입 wx.login 하고 이를 WeChat 애플릿 형식으로 반환합니다 code.
2단계: 미니 프로그램은 수정할 필요가 없으며 WeChat 구현에 따라 code 이때 개발자 서버로 전송됩니다.
3단계: 개발자 서버를 조정하고 code 로그인이 FinClip 플랫폼에서 온 것인지 확인 code 하고 이를 구문 분석한 UserID후 자신의 계정 시스템의 콘텐츠를 반환합니다.

옵션 2: 서버측 변환 + WeChat 인증

서버측 변환 및 WeChat 인증 통합 시나리오는 주로 "고객이 FinClip을 통해 원본 앱에서 관련 기능 분할을 완료하는 경우에 적용됩니다. 실제 작업 프로세스에서는 모든 작은 프로그램이 사내 R&D 팀에 의해 수정 및 통합됩니다. ."

이 경우 고객은 다음 링크에서 관련 수정 비용을 투자해야 합니다.

1단계: WeChat 개발 플랫폼 SDK를 SDK에 통합합니다.
2단계: WeChat 인증을 활성화한 후 사용자 지정 API 주입을 사용하여 wx.login반환 코드를 얻습니다. 이때 코드에 고유 식별자를 연결해야 할 수도 있습니다.
3단계: 미니 프로그램은 수정할 필요가 없으며 WeChat 구현에 따라 이때 코드가 개발자 서버로 전송됩니다.
4단계: 서버는 다양한 인증 인터페이스를 호출하여 코드를 기반으로 고유 식별자를 획득 OpenID하고 로그인 상태를 쿼리하여 반환합니다.

다양한 주제에 대한 WeChat의 제한으로 인해 다양한 개방형 플랫폼의 주제는 일관성이 없습니다. 이때 미니 프로그램은 동일한 주제 또는 동일한 개방형 플랫폼과 연결되어야 합니다(현재 고유 식별자는 ) . . OpenID UnionID

옵션 3: 미니 프로그램 변환

미니 프로그램 수정의 사용 시나리오는 주로 고객이 프로덕션 환경에서 사용할 수 있는 미니 프로그램을 이미 가지고 있지만 미니 프로그램의 내용을 논리적으로 수정하고 환경 변수를 추가해야 하는 경우(예: 사용자 정의 API 또는 이와 유사한 기능을 통해)입니다 . wx.login ) wx.loginFinClip판단하세요(물론 이 경우에는 작은 프로그램 코드를 편집할 수 있는 능력도 필요합니다).

이 경우 주로 자신의 앱에 맞춤 API 삽입을 통해 wx.login 현재 사용자의 로그인 상태를 가져와야 합니다.

샘플 코드: 미니 프로그램 변환 + 맞춤형 API

위의 옵션 3을 기반으로 참조용으로 해당 샘플 코드도 제공합니다. 미니 프로그램 로그인 FAQ

본 문서에서는 "WeChat 로그인에 액세스하는 앱", "사용자 정의 주입 인터페이스를 구현하는 앱" 및 "인터페이스 호출을 구현하는 미니 프로그램"에 대한 관련 코드를 제공합니다.