このフローを使用できる状況

App ID が特定の ID プロバイダーを直接サポートしていない場合、App ID の既存の認証フローと認証プロトコルの間のブリッジとして、カスタム識別フローを使用することができます。 例えば、GitHub または LinkedIn を使用してユーザーにサインインを許可するとします。 ユーザー認証情報を容易に扱えるように ID プロバイダーの既存の SDK を使用してから、その情報をパッケージして App ID と交換することができます。

別の認証フローが必要になるシナリオは、以下のように多数あります。

• 専有の社内 ID プロバイダー
• サード・パーティーの ID プロバイダー
• 複雑な認証フロー (独自の多要素メカニズムが組み込まれていることがあります)

場合によっては、レガシー・プロバイダーで独自のカスタム認証プロトコルが使用されていることがあります。 カスタム識別フローによって認証が許可から完全に分離されるため、任意の認証メカニズムを採用し、それから得られる認証情報を App ID に提供することができます。 これらの処理はすべて、ユーザー資格情報を露出せずに実行できます。

このフローの技術的な仕組み

カスタム ID ワークフローは、Assertion Framework for OAuth 2.0 Authorization Grants [RFC7521 ] で定義されている JWT-Bearer 拡張グラント・タイプに基づいて構築されている。 App ID トークンのユーザー情報を交換するために、認証アーキテクチャーで、非対称 RSA 鍵ペアを使用して App ID との信頼関係を確立します。 信頼関係が確立されたら、JWT-Bearer 付与タイプを使用することで、App ID のトークンの署名付き JWT 内にある、検証済みユーザー情報を交換できます。

フローの概要

あらゆる認証フローの場合と同様に、カスタム識別を使用する場合も、ID プロバイダーのユーザー情報の整合性を確保するため、アプリケーションが App ID との一定レベルの信頼関係を確立できるようにする必要があります。 カスタム識別の場合、非対称 RSA 公開鍵/秘密鍵ペアを使用して、信頼関係を確立します。 カスタム識別は、アーキテクチャーの要件に基づいて 2 種類の信頼モデルをサポートします。2 つの違いはストレージ・ロケーションと秘密鍵の使用法のみです。

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"
}