어떤 경우에 이 플로우를 사용합니까?

App ID에서 특정 ID 제공자에 대한 직접 지원을 제공하지 않을 경우 사용자 정의 ID 플로우를 사용하여 인증 프로토콜을 App ID의 기존 인증 플로우에 브릿징할 수 있습니다. 예를 들어 사용자가 사인인할 수 있도록 허용하기 위해 GitHub 또는 LinkedIn을 사용할 수 있습니다. App ID를 통해 사용자 인증 정보를 패키징 및 교환하기 전에 ID 제공자의 기존 SDK를 사용하여 해당 사용자 인증 정보를 활용할 수 있습니다.

다른 인증 플로우가 필요한 다양한 시나리오가 존재합니다.

• 소유권, 사내 ID 제공자
• 서드파티 ID 제공자
• 소유권 다단계 메커니즘을 포함시킬 수 있는 복잡한 인증 플로우

레거시 제공자가 고유한 사용자 정의 인증 프로토콜을 사용할 수 있는 경우도 있습니다. 사용자 정의 ID 플로우의 경우 인증을 권한 부여와 완전히 분리하기 때문에 원하는 인증 메커니즘을 채택한 후 결과 인증 정보를 App ID에 제공할 수 있습니다. 모두 사용자 인증 정보가 노출되지 않습니다.

이 플로우는 기술적으로 어떻게 작동합니까?

사용자 지정 ID 워크플로우는 OAuth 2.0 권한 부여 [RFC7521 ]에 대한 어설션 프레임워크에 정의된 JWT-Bearer 확장 권한 부여 유형을 기반으로 구축됩니다. App ID 토큰에 대한 사용자 정보를 교환하려면 인증 아키텍처는 비대칭 RSA 키 쌍을 사용하여 App ID과(와)의 신뢰 관계를 작성합니다. 신뢰가 설정되면 JWT-Bearer 권한 부여 유형을 사용하여 App ID 토큰에 대해 서명된 JWT 내에 있는 확인된 사용자 정보를 교환할 수 있습니다.

이 플로우의 형태는 어떻습니까?

모든 인증 플로우와 마찬가지로 사용자 정의 ID의 경우에도 ID 제공자 사용자 정보의 무결성을 위해 애플리케이션에서 App ID와 일정 수준의 신뢰를 설정할 수 있어야 합니다. 사용자 정의 ID는 비대칭 RSA 공개 및 개인 키 쌍을 사용하여 신뢰 관계를 설정합니다. 아키텍처의 요구사항에 따라 사용자 정의 ID는 스토리지 위치 및 개인 키의 사용법에서만 차이가 있는 두 가지 신뢰 모델을 지원합니다.

JWT 형식 예제

{
  // Header
  "alg": "RS256",
  "typ": "JOSE",
  // Payload
  // Required
  "iss": "String", // Should reference your identity provider
  "aud": "String", // Must be the OAuth server URL name
  "exp": "Int",    // Should be a value with a short lifespan
  "sub": "String", // Must be the unique user ID provided by your identity provider

  // Normalized claims (optional)
  "name": "String",
  "email": "String",
  "locale": "String",
  "picture": "String",
  "gender": "String",

  // Custom Scopes to add to access token (optional)
  scope="custom_scope1 custom_scope2"

  // Other custom claims (optional)
  role="admin"
}