メインコンテンツまでスキップ

認可コードフロー

前提知識​

このドキュメントを理解するには、以下の基礎知識が役立ちます：

概要​

idp-serverは、OAuth 2.0 および OpenID Connectに準拠した認可コードフローを提供します。
さらに、下記の拡張仕様をサポートしています。

  • Financial-grade API (FAPI)
  • OIDC4IDA
  • RFC 7636（PKCE）
  • Rich Authorization Request（RAR）
  • Pushed Authorization Request (PAR)
  • etc

シーケンス​

  1. クライアントは認可リクエストをidp-serverにリクエストを行います。
  2. idp-serverは認可リクエストが仕様に準拠しているかを検証します。
  3. idp-serverは テナントの認可画面のURL をクライアントに返却します。
  4. クライアントは302リダイレクトに応じて、テナントの認可画面を表示します。
  5. 認可画面は テナントの認証ポリシー に応じて、ユーザーとの認証を開始します。パスワード / Passkeyなど
  6. idp-serverはユーザーとの認証結果と認証ポリシーを比較します。認証ポリシーを満たしている場合は認証完了とします。
  7. idp-serverは認証完了を認可画面に返却します。
  8. 認可画面は同意画面を表示します。
  9. ユーザーが同意した場合、認可画面はidp-serverに同意のリクエストをします。
  10. idp-serverは認証が完了しているかをチェックします。
  11. idp-serverは認証が完了している場合、認可コードを生成します。
  12. idp-serverは認可画面に認可コード付きのリダイレクトURLを含むレスポンスを返却します。
  13. 認可画面を認可コード付きのリダイレクトURLにリダイレクトします。
  14. クライアントはリダイレクトURLから認可コードを抽出し、idp-serverにトークンリクエストを行います。
  15. idp-serverは認可コードの検証を行います。
  16. idp-serverはトークンを生成し記録します。
  17. idp-serverはアクセストークン + IDトークン + リフレッシュトークンをレスポンスします。

認証​

方式​

認可画面で実施する認証はテナントの認証ポリシーに応じて、下記の方式を柔軟に実施することが可能です。

方式説明
初期登録IDの属性情報の登録
PasswordユーザーIDとパスワードによる認証。
SMSSMS番号登録用の認証コード送信。
Emailメールリンクによるワンタイム認証。
FIDO-UAFFIDO-UAFによる登録チャレンジ生成。
WebAuthnWebAuthn（Passkeyなど）の登録チャレンジ生成。
デバイスCIBAやデバイス連携による認証通知。
レガシー外部レガシーIDサービス連携による認証。

例えば、

  1. Password認証
  2. SMS認証
  3. Email認証

のような他要素認証を実施することができます。

認証デバイスへのステップアップ​

ブラウザとは別の認証デバイス（スマートフォンアプリ等）に認証を委ねる場合、サインイン画面とデバイスが別チャネルで進行するデカップルド型になります。開始時にクライアント認証が無いため、プッシュ疲労対策としてナンバーマッチングを併用します。

詳細は 認可コードフロー デバイス認証拡張 を参照してください。

また、認証の順序も認証ポリシーで制御可能です。

  1. Password認証
  2. Email認証
  3. SMS認証

のように順序を入れ替えることも可能です。

さらに、Password認証が不要であれば、Webauthn（Passkey）のみの設定も可能です。

認証ポリシー（概要）​

テナントに複数の認証ポリシーを設定できます。

項目説明
conditions適用条件。acr_values, scopes, authorization_flowなどを指定
available_methods利用可能な認証方式のリスト（UIや内部フローで利用）
success_conditions認証成功とみなす条件
failure_conditions警告や統計記録の対象となる失敗条件
lock_conditionsアカウントロックや認可拒否に至る失敗条件

設定​

idp-serverは、OAuth 2.0 および OpenID Connectに準拠した設定をサポートしています。

拡張設定​

また、仕様には定義されていないけれど、認可コードフローを実現するために必要な項目も設定が可能となっています。

項目説明デフォルト値
authorization_code_valid_duration認可コードの有効期限600秒
access_token_durationアクセストークンの有効期限1800秒
refresh_token_durationリフレッシュトークンの有効期限3600秒
id_token_durationIDトークンの有効期限3600秒
id_token_strict_modeスペックに準拠させ、スコープ等によるカスタムクレームの設定が付加。false
default_max_ageデフォルトのセッションの有効期限86400秒
authorization_response_durationJARMの有効期限60秒
oauth_authorization_request_expires_in認可リクエストの有効期限1800秒
access_token_type識別子(opaque) or 内包型(JWT)opaque

FAPIプロファイル​

idp-serverは、FAPIプロファイルをサポートしています。

FAPIプロファイルの適用をスコープで判断します。

項目説明デフォルト値
fapi_baseline_scopesBaselineのプロファイルを提供するスコープ空配列
fapi_advance_scopesAdvanceのプロファイルを提供するスコープ空配列

認可リクエストに設定したスコープを含む場合に、FAPIプロファイルに応じた認可リクエスト・トークンリクエストの検証を実施します。

OIDC4IDA​

idp-serverは、OIDC4IDAをサポートしています。

また、身元確認サービスとの連携機能も備えておりエンドユーザーからの申込みベースで身元確認済みのクレームを登録することができます。

便利機能​

idp-server は便利機能をいくつか用意しており、主な機能は下記2つとなります。

  1. claims:xx スコープによるIDトークン・アクセストークンクレームの動的設定
  2. verified_claims:xx スコープによるアクセストークンのプロパティの動的設定

claims:xx スコープによるIDトークン・アクセストークンクレームの動的設定​

idp-server では、スコープに claims:プレフィックス付きスコープが含まれる場合、ユーザーのカスタム属性やロール情報を動的に IDトークンとアクセストークンに含めることができます。

注意: id_token_strict_mode 設定はIDトークンへの追加時のみ適用され、アクセストークンには影響しません。

これは ScopeMappingCustomClaimsCreator により実現され、以下の条件で動作します：

  • custom_claims_scope_mapping が有効であること
  • 対象スコープに claims: プレフィックスが含まれていること

IDトークンへの追加時の追加条件：

  • id_token_strict_mode が無効であること

対象スコープが claims:roles の場合、ユーザーが持つロール一覧（リスト形式）が roles クレームとして付加されます。

同様に claims:assigned_tenants や claims:assigned_organizations を指定することで、関連するテナントや組織のIDを含めることも可能です。

verified_claims:xx スコープによるアクセストークンのプロパティの動的設定​

idp-server では、スコープに verified_claims:プレフィックス付きスコープが含まれる場合、身元確認済みの属性を アクセストークンに含めることができます。

これは AccessTokenSelectiveVerifiedClaimsCreator により実現され、以下の条件で動作します：

  • enabled_access_token_selective_verified_claims が有効であること
  • 対象スコープに verified_claims: プレフィックスが含まれていること
  • ユーザーが該当の verified_claims 属性を所持していること

対象スコープが verified_claims:name の場合、ユーザーが持つverified_claimsの name をプロパティに設定します。

参考資料​

標準仕様​

関連ドキュメント​