카우치베이스 동기화 게이트웨이에서 클라이언트 인증을 위한 OIDC 인증 코드 흐름 [3부 3편]

카우치베이스 동기화 게이트웨이 지원 OpenID Connect 또는 OIDC 기반 클라이언트 인증.

이러한 맥락에서 클라이언트 를 사용하여 인터넷을 통해 동기화 게이트웨이와 데이터를 동기화하는 카우치베이스 라이트 클라이언트일 수 있습니다. 웹소켓 기반 복제 프로토콜 또는 동기화 게이트웨이를 통해 액세스하는 웹 프론트엔드 또는 모바일 앱일 수 있습니다. 공용 REST 엔드포인트.

이 시리즈의 첫 번째 블로그 게시물에서는 다음과 같이 설명했습니다. OIDC 및 OAuth2 인증 및 권한 부여 흐름의 기본 사항 그리고 지난주 블로그 게시물에서 더 자세히 알아보았습니다. OIDC 암시적 흐름 기반 동기화 게이트웨이 클라이언트 인증.

이 게시물에서는 다음과 같은 내용을 소개합니다. OIDC 인증 코드 흐름 기반 클라이언트 인증은 Couchbase 동기화 게이트웨이 복제 컨텍스트 내에서만 가능합니다.

이 게시물은 인증 및 권한 부여를 위한 OIDC 및 OAuth2 플로우에 익숙하다고 가정합니다. 이러한 흐름에 익숙하지 않거나 다시 한 번 복습이 필요한 경우 위에 링크된 이전 블로그 게시물을 참조하세요.

카우치베이스 동기화 게이트웨이 OIDC 구성

그리고 카우치베이스 동기화 게이트웨이 는 OIDC 인증을 위해 구성해야 합니다. 데이터베이스별로.

다음은 인증 코드에 대한 기본 OIDC 구성입니다. 자세한 내용은 공식 Couchbase 설명서를 참조하세요. 모든 OIDC 구성 옵션의 전체 목록.

• 발행자 는 OIDC ID 공급자에 해당하는 인증 URL입니다.
• client_id 는 OIDC 제공업체에 앱을 등록하는 과정의 일부로 생성됩니다. 여기서 클라이언트는 카우치베이스 라이트 앱 또는 웹 앱으로 이동합니다. 참고 client_id 는 기술적으로 리소스 소유자인 앱의 최종 사용자와 일치하지 않습니다.
• 유효성 검사 키 에 해당하는 클라이언트_비밀 를 생성해야 하며, OIDC 제공업체에 앱 등록 프로세스의 일부로 생성해야 합니다.
• callback_url 는 클라이언트가 ID 토큰(ID 토큰)을 획득한 후 동기화 게이트웨이에서 리디렉션할 URL입니다.
• 등록 플래그, 설정된 경우 true를 입력하면 ID 토큰 유효성 검사에 성공한 후 동기화 게이트웨이에 사용자가 자동으로 생성됩니다.
• 사용자명_클레임 는 동기화 게이트웨이 사용자 이름으로 사용할 JWT 클레임에 해당합니다. 기본적으로 동기화 게이트웨이 사용자 이름은 다음과 같은 형식을 취합니다. 발행자+주체 어디 발행자 사용자 이름을 나타냅니다. 접두사. 접두사 값은 기본적으로 발급자 클레임으로 설정되며, 다른 클레임 값을 사용하도록 사용자_프리픽스 구성 옵션.
• disable_session로 설정한 경우 true를 사용하여 인증 성공 후 동기화 게이트웨이의 자동 세션 생성을 재정의할 수 있습니다.

카우치베이스 동기화 게이트웨이 OIDC 검색

시작 시 동기화 게이트웨이는 다음에 연결됩니다. 구성된 OIDC 공급자/발급자와 연결된 검색 엔드포인트 를 사용하여 관련 공급자 메타데이터를 가져옵니다. 그리고 메타데이터에는 토큰 유효성 검사에 필요한 관련 정보가 포함됩니다. 발급자 공개 키, ID 토큰의 클레임 인코딩에 사용되는 지원되는 암호화 알고리즘 등입니다.

검색 엔드포인트는 발급자와 연결된 잘 알려진 검색 URL에 해당합니다. 필요한 경우 다음을 통해 URL을 재정의할 수 있습니다. 동기화 게이트웨이 discovery_url 구성 옵션.

클라이언트 인증을 위한 OIDC 인증 코드 흐름

이 플로우는 다음에서 설명하는 표준 OIDC 인증 코드 플로우를 기반으로 합니다. OIDC 기본 블로그(시리즈 1편).

인증

1. 사용자가 카우치베이스 라이트 클라이언트 앱에 로그인하면, 클라이언트는 다음을 호출합니다. _oidc REST 엔드포인트 를 클릭하여 동기화 게이트웨이에서 OIDC 인증 코드 흐름을 시작합니다.
2. 동기화 게이트웨이가 클라이언트 앱을 OIDC 공급자 URL로 리디렉션합니다.
3. 클라이언트는 인증 코드를 검색하기 위해 OIDC 공급자와 함께 인증 코드 플로우를 시작합니다. 이는 다음에 설명된 표준 OIDC 플로우 절차에 따릅니다. OIDC 기본 블로그.
4. 클라이언트는 인증 코드와 함께 동기화 게이트웨이로 리디렉션됩니다. 리디렉션 URL은 다음에 해당합니다. OIDC 콜백 REST 엔드포인트.
5. 클라이언트 앱은 인증 코드를 사용하여 OIDC 콜백 REST 엔드포인트를 호출합니다.
6. 동기화 게이트웨이는 OIDC 공급자에게 적절한 요청을 전송하여 ID 토큰, 새로 고침 토큰 및 액세스 토큰에 대한 코드를 교환합니다. 요청에는 다음이 포함됩니다. client_id 그리고 클라이언트_비밀 를 동기화 게이트웨이에 구성했습니다. 이를 통해 OIDC 공급자는 신뢰할 수 있는 클라이언트만 토큰을 검색할 수 있는지 확인할 수 있습니다.
7. 동기화 게이트웨이는 로컬에서 ID 토큰의 유효성을 검사합니다. 토큰 유효성 검사가 성공적으로 완료되면 해당하는 UserCtx 객체가 생성됩니다.
   • 시작 시 OIDC 공급자 검색 URL에서 검색된 메타데이터는 "오프라인 모드"에서 토큰의 유효성을 검사하는 데 사용됩니다.
   • 사용자가 동기화 게이트웨이로 인증하는 것이 처음이고 해당 사용자가 서버에 없는 경우, 동기화 게이트웨이가 자동으로 사용자를 생성합니다. 등록 구성 옵션이 true.
     • 참고: 생성된 사용자는 다음과 같은 액세스 권한 부여와 연결되지 않습니다. 채널 또는 역할를 사용하므로 이 자동 등록은 사용자별 액세스 권한이 없는 공개 사용자에 대해 작동합니다. 이 글의 뒷부분에서 사용자별 액세스 권한이 있는 사용자를 만드는 방법을 설명하는 흐름에 대해 설명하겠습니다.
   • 유휴 세션 시간 제한이 24시간인 사용자에 대한 세션이 만들어집니다. 세션이 만들어집니다. 다음과 같은 경우에만 의 disable_session 가 거짓으로 설정되어 있습니다.
8. 세션 ID와 새로 고침 토큰이 클라이언트 앱으로 다시 전송됩니다.
9. 클라이언트 앱은 다음과 같이 복제를 시작합니다. 를 사용하여 세션 ID를 세션 쿠키로 설정합니다. 세션 인증자.
10. 동기화 게이트웨이는 세션의 유효성을 확인하여 세션이 삭제되었는지 또는 만료되었는지 확인합니다.
    • 세션이 활성 상태인 경우, 유휴 세션 시간 제한 10%가 경과하면 세션이 24시간으로 자동 연장됩니다.
11. 초기화에 성공하면 복제가 평소와 같이 진행되며 클라이언트 앱과 동기화 게이트웨이 측의 문서 변경 사항이 동기화됩니다.
    • 활성 복제 중에 사용자가 삭제되면 복제가 종료됩니다.
    • 사용자와 관련된 액세스 권한이 변경된 경우 업데이트된 액세스 권한의 영향을 받는 문서는 복제되지 않습니다. 예를 들어 사용자가 채널에 대한 액세스 권한을 상실하면 해당 채널의 문서는 가져오지 않습니다.

토큰 새로 고침

인증 코드 흐름의 장점 중 하나는 ID 토큰 외에 새로 고침 토큰도 클라이언트 앱에 반환된다는 것입니다. 클라이언트 앱은 새로 고침 토큰을 사용하여 최종 사용자가 로그인 자격 증명으로 재인증할 필요 없이 자동으로 새 인증 코드를 요청할 수 있습니다.

1. 클라이언트 앱이 토큰을 새로 고치려면 새로 고침 토큰을 사용하여 OIDC 새로 고침 REST 엔드포인트에 요청합니다.
2. 동기화 게이트웨이는 OIDC 공급자에게 적절한 요청을 전송하여 새로 고침 토큰을 업데이트된 ID 토큰 및 액세스 토큰으로 교환합니다. 요청에는 client_id 그리고 클라이언트_비밀 를 동기화 게이트웨이에 구성했습니다. 이를 통해 OIDC 공급자는 신뢰할 수 있는 클라이언트만 토큰을 검색할 수 있는지 확인할 수 있습니다.
3. 동기화 게이트웨이는 로컬에서 ID 토큰의 유효성을 검사합니다. 토큰 유효성 검사가 성공적으로 완료되면 해당하는 UserCtx 객체가 생성됩니다.
   • 시작하는 동안 OIDC 공급자 검색 URL에서 검색된 메타데이터는 "오프라인 모드"에서 토큰의 유효성을 검사하는 데 사용됩니다.
   • 유휴 세션 시간 제한이 24시간인 사용자에 대한 새 세션이 만들어집니다. 세션이 만들어집니다. 다음과 같은 경우에만 의 disable_session 가 거짓으로 설정되어 있습니다.
4. 세션 ID와 ID 토큰이 클라이언트 앱으로 다시 전송됩니다.
5. 클라이언트 앱은 이전 흐름과 동일한 단계에 따라 세션 ID를 세션 쿠키로 사용하여 복제를 시작합니다.

인증된 사용자에게 액세스 권한 연결하기

동기화 게이트웨이 채널 그리고 역할 는 동기화 게이트웨이의 액세스 제어 메커니즘의 두 가지 핵심 요소입니다. 이들은 액세스 권한 부여 사용자와 연결된 문서 집합을 지정하여 사용자가 읽기 및 쓰기 액세스 권한을 가진 문서 집합을 지정합니다.

사용자에게 액세스 권한을 할당하는 몇 가지 옵션이 있습니다:

• 동기화 기능을 통해 사용자를 채널 또는 역할에 동적으로 할당합니다. access() 또는 역할() API를 사용하는 액세스 권한 부여 문서 사용자에게 할당해야 하는 채널 또는 역할을 지정합니다.
• 관리자를 통해 사용자에게 보조금 정적 할당 _user REST API.

이전 흐름에서 보았듯이, 인증에 성공한 후 동기화 게이트웨이에서 인증된 사용자를 자동으로 생성하도록 Couchbase 동기화 게이트웨이를 구성할 수 있습니다. 그러나 생성된 사용자는 액세스 권한 부여와 연결되지 않습니다. 이는 공개 채널 액세스 권한이 있는 공개 사용자에 대해 작동합니다.

하지만 사용자별 액세스 권한을 할당하려면 어떻게 해야 할까요? 이 작업은 일반적으로 사용자 생성 또는 업데이트를 담당하는 백엔드 애플리케이션 서버를 통해 처리됩니다. 동기화 게이트웨이는 OIDC 인증만 담당합니다.

다음은 일반적인 흐름입니다:

1. 백엔드 프로세스 또는 앱 서버는 OIDC 공급업체에 사용자를 등록하는 역할을 담당합니다.
2. 등록 후 앱 서버는 동기화 게이트웨이에 해당 사용자를 생성합니다. _user REST API 또는 적절한 액세스 권한 부여 문서를 추가합니다.
3. 다음에 사용자가 앱에 로그인할 때 앞서 설명한 인증 코드 흐름 절차를 사용하여 OIDC 인증이 진행됩니다.
4. OIDC 플로우 유형에 관계없이 동기화 게이트웨이에서 ID 토큰의 유효성을 검사하면 동기화 게이트웨이는 이미 존재하므로 사용자를 만들지 않습니다.
5. 복제는 인증된 사용자를 사용하여 평소와 같이 진행됩니다.
6. OIDC 공급자에서 사용자가 업데이트되면 앱 서버는 동기화 게이트웨이에서 해당 사용자를 업데이트합니다. _user REST API 또는 액세스 권한 부여 문서를 업데이트합니다.
   • 활성 복제 중에 사용자가 삭제되면 복제가 종료됩니다.
   • 사용자와 관련된 액세스 권한이 변경된 경우 업데이트된 액세스 권한의 영향을 받는 문서는 복제되지 않습니다. 예를 들어 사용자가 채널에 대한 액세스 권한을 상실하면 해당 채널의 문서는 가져오지 않습니다.

자주 묻는 질문(FAQ)

암시적 흐름과 인증 코드 흐름 중 어느 것이 더 낫나요?

제 관점에서는 선호하는 흐름이 없습니다. 암시적 흐름은 간단하며 일반적으로 대부분의 사용자가 선호합니다. 모바일 앱에는 보안 저장소가 있기 때문에 ID와 액세스 토큰을 디바이스의 로컬 키 저장소에 안전하게 저장할 수 있습니다. 이 블로그 게시물에서 자세한 내용을 확인할 수 있습니다. 동기화 게이트웨이 인증에 OIDC 암시적 흐름을 활용하는 방법.

인증 코드 흐름의 장점은 약간 더 나은 보안을 제공한다는 것입니다. OIDC 공급자에게 유효한 인증 코드가 제시된 경우에만 인증 코드와 교환하여 토큰이 동기화 게이트웨이에 부여되기 때문입니다. client_id 그리고 클라이언트_비밀. 이렇게 하면 인증된 클라이언트만 토큰을 받을 수 있습니다. 또한 새로 고침 토큰을 사용하면 최종 사용자가 매번 자격 증명을 입력할 필요 없이 인증 세션을 새로 고칠 수 있습니다.

추가 리소스

이 글에서는 동기화 게이트웨이의 OIDC 인증 지원에 대해 설명했습니다. 다음은 확인해 볼 수 있는 몇 가지 추가 리소스입니다:

• 튜토리얼: 동기화 게이트웨이와 함께 KeyCloak OIDC 공급자를 사용한 OIDC 인증
• 문서: 동기화 게이트웨이 OIDC 구성
• 문서: 동기화 게이트웨이 클라이언트 인증

질문이나 피드백이 있으시면 아래에 댓글을 남기거나 다음 주소로 이메일을 보내주세요. priya.rajagopal@couchbase.com. . 카우치베이스 포럼 를 통해 질문할 수 있습니다.

감사

동기화 게이트웨이 설계자에게 감사드립니다. 아담 프레이저 이 블로그 게시물에 대한 그의 의견에 감사드립니다.
 

인증 및 권한 부여에 관한 이 시리즈의 나머지 포스팅도 놓치지 마세요: