カーネル内のOAuth2/OpenIDを接続する

OIDC over OAuth2は、ユーザー/クライアントが誰であるかを証明し、短命なAPIアクセスを与えるための標準的な方法です。プラットフォームの中核で、それは中心的な機能になります：顧客、オペレーター、サービスのシングルサインオン；最小権限；測定可能なリスク；地域およびライセンス規制の遵守。

1）目標と原則

分離「deploy vs enable」：コードを個別にロールアウトし、フラグ/ポリシーでアクセスを有効にします。
短命トークン+安全なアップデート：リークによるダメージを軽減します。
マルチテナント/リージョン：すべてのアーティファクトに「テナント/リージョン/ライセンス」というラベルが付けられています。
トークンの上のポリシー：ソリューションは、PDP （RBAC/ABAC）、ゲートウェイ/サービスのPEPによって作成されます。
リンク保護：TLS1。2+、可能であればmTLS/DPoP、厳密なCORS/CSRF。
観測性と監査：ストリーム別、顧客別、地域別の可視性。

2）フローと適用時期

認可コード+PKCE （SPA/Mobile/Web）-ユーザログインのデフォルト。
デバイス認証（コンソール/テレビ/CLI）-ブラウザがない場合。
Client Credentials （machine-to-machine）-ユーザーなしのサービス統合。
トークン交換（RFC 8693、 OBO）-サービスはユーザーに代わって動作します。
CIBA/バックチャネル（オプション）-リダイレクトせずにプッシュ認証。

デフォルトで有効にする拡張機能：

PAR （Push Authorization Requests）-認証パラメータは安全なサーバーチャネル経由で送信されます。
JWT Secured Authorization-リクエストパラメータは署名/暗号化されます。
JARM-保護された承認応答（JWT）、なりすましに強い。
RAR （Rich Authorization Requests）-リッチアクセス権リクエスト（詳細な権限）。

3）トークンとスタンプ

タイプ：

IDトークン（OIDC）-入力した人（クライアント/フロントにのみ表示）。
アクセストークン（AT）-アクションの権利（短命）。
リフレッシュトークン（RT）-更新AT；信頼できる環境にのみ保存されます。

タイミングの推奨事項：

AT： 5-15分（ウェブ/モバイル）、2-5分（サービス間）。
RT： 7-30 （web/mobile）回転+再利用検出。
ID： ≤ 5分。

最小ATスタンプ（例）：

json
{
"iss":"https://auth. core",
"sub":"user_42",
"aud":["wallet","catalog"],
"exp":1730388600,"iat":1730388000,
"tenant":"brand_eu","region":"EE","licence":"EE-A1",
"scp":["wallet:read","bets:place"],     // scopes
"sid ": "sess _ abcd, ""amr": [" pwd,"" webauthn"] ,//login methods
"act":{"sub":"svc. catalog" }//if OBO
}

署名：ES256/EdDSA、公開鍵-JWKSの「子供」と回転。

4）セッション概要とログアウト

サーバー側のセッションWeb （Cookie 'SameSite=Lax/Strict'、 'HttpOnly'、 'Secure'）。
バックチャンネルログアウト+フロントチャンネルログアウト（OIDC）-すべてのクライアントの同期終了。
ステップアップMFA：敏感なアクションで-繰り返しチェック（'acr'増加）。
失効とイントロスペクション：インシデントによってRT/ATを即座に無効にします。

5）顧客の保証

Web/SPA：承認コード+PKCE、暗黙的な；厳密なCORS/Content-Security-Policy。
モバイル：システムブラウザ（AppAuth）、整合性チェック（App Attestation/DeviceCheck）、安全なRTストレージ。
デスクトップ/CLI/TV：デバイスフロー；OSの秘密ストアにRTを格納します。
ATをデバイス/接続にバインドするためのDPoPまたはmTLSバインドトークン。

6）サービス・ツー・サービス

mTLS+short Service JWT （aud-scoped）は、KMS/HSMでSTSを発行します。
ワークロードのアイデンティティ：SPIFFE/SPIRE。

狭い範囲のポリシー： 代わりに特定のオーディエンスとスコープ"

7）スコープ-レジストリと同意

名前： 'resource： action'-'wallet： read'、 'wallet： transfer'、 'bets： place'、 'kyc： status。「読む」

スコープの可視性と感度を設定します。
同意画面はRAR/Scopesから組み立てられます。同意履歴を保持し、フィードバックを許可します。

RAR（ウォレット→翻訳）の例：

json
{
"type":"wallet. transfer",
"actions":["create"],
"locations":["https://api. core/wallet"],
"datatypes":["payment"],
"resources":[{"wallet_id":"w_123","currency":"EUR","amount_max":1000}]
}

8）承認統合（PDP/PEP）

Gateway APIのPEPはAT/DPoP/mTLSを検証し、コンテキスト（IP/ASN/region/tenant）を強化し、PDPへの要求を行います。
PDP （OPA/cedar）はRBAC/ABAC/ReBACポリシーを適用し、説明とTTLとともに「ALLOW/DENY」を返します。
PEP （TTL 30-120 s）のソリューションキャッシュで、イベントによる障害（役割/ルールの変更）。

9）複数のテナントおよび地域

すべてのトークンとセッションは'tenant/region/license'というラベルが付けられています。PDPはリソースのコンプライアンスを検証します。
JWKS/keysを分離し、地域ごとにリストをリコールします。クロスリージョン-信頼できるゲートウェイを介して。
データレジデンスの制限：イントロスペクション/失効は原産地で実行されます。

10）プロトコルアンプ

PAR+JAR+JARM-承認パラメータと応答を保護します。
Nonce/State/PKCE-すべての公共の顧客向け。
プッシュデバイス認証（高リスク）。
イントロスペクションを介した外部統合のための最小限のスタンプ+不透明なオプションを備えたJWTアクセストークン。
FAPIのようなプラクティス：厳格な署名アルゴリズム、TLS/redirect_uri/PKCE要件。

11）エラーと返品ポリシー

応答の標準化：

json
{ "error":"invalid_grant", "error_description":"refresh token reused", "error_code":"RT_REUSE" }

「無効なリクエスト」「、無効なクライアント」「、無効なグラント」「、無効なスコープ」「、許可されていないクライアント」「、access_denied」「、temporally_unavailable」。
敏感なエンドポイント（'/token'、'/introspect'、 '/revoke'）、指数関数的なバックオフのレート制限。

12）可視性と監査

メトリクス：

'auth_code_success_rate'、 'pkce_missing_rate'、 'mfa_challenge/fail_rate'、
'token_issuance_p95_ms'、 'jwks_skew_ms'、 'invalid_token_rate'、 'rt_reuse_detected'、
API： 'authz_p95_ms'、' deny_rate {reason}'、'dpop_mismatch_rate'、'mtls_fail_rate'。

'client_id'、 'grant_type'、 'kid'、 'acr/amr'、 'tenant/region'、 'decision'、 'policy_version'、 'aud'、 'scp'、 'sid'、 'trace_id'。
監査（変更不可）：トークンの発行、権利のエスカレーション、同意の撤回、キーのローテーション。

13）キー管理および回転

JWT signature： KMS/HSM、 JWKS publication with 'kid'。
デュアルキー期間：IdPは新しいサイン、レビュアーは切り替える前に古い+新しいを受け入れます。
規則的な回転および緊急の取り消し；「子供」の消費量の監視。

14）プレイブック（ランブック）

1.シグネチャーキーの妥協

すぐに「子供」を取り消し、新しい、強制的に無効なRT/セッション、監査レポートを発行します。

2.マス'invalid_token '/growth 401

Check clock misalignment、 expired AT、 broken JWKS cache；一時的に'clock_skew'許容値を増加させます。

3.RT再利用

セッション（'sid'）をブロックし、ユーザーに通知し、新しいログインのステップアップを要求し、調査します。

4.IdPドロップ

「読み取り専用認可」モードを有効にする：アクティブなATをTTLまで保持し、新しいログインを制限し、イントロスペクションキャッシュをスケールします。

5.'/token'への攻撃'

レートリミット/ボットフィルタを強化し、機密クライアントのmTLS/DPoPを有効にし、コールドRTを別のセグメントに移動します。

15）テスト

契約：OIDCディスカバリ、JWKS、 OpenIDプロバイダ設定。
セキュリティ：PKCE/nonce/stateが必要です。negative-set（置換'redirect_uri'、 RTを再利用）。
相互運用性：クライアント（Web/モバイル/CLI）、異なるタイムゾーン/ロケール。
カオス：PAR/JARMの故障、JWKSの遅延、即座に「子供」を回転させた。
E2E：ステップアップMFA、 OBO（トークン交換）、ログアウト（フロント/バックチャネル）、取り消し/回転。

16）構成例

OIDC/Authorization Server （YAMLフラグメント）：

yaml issuer: https://auth. core jwks:
rotation_days: 30 alg: ES256 tokens:
access_ttl: 10m refresh_ttl: 14d id_ttl: 5m policies:
require_pkce: true require_par: true require_jarm: true dpop_enabled: true mfa_step_up:
actions: ["wallet:transfer","payout:initiate"]
tenancy:
include_claims: ["tenant","region","licence"]
jwks_per_region: true

スコープレジストリ：

yaml scopes:
wallet: read: {desc: "Reading balance"}
wallet: transfer: {desc: "Transfer of funds," sensitive: true, step_up: true}
bets: place: {desc: "Betting"}
kyc:status. read: {desc: "KYC status"}
roles:
player: { allow: [bets:place] }
support: { allow: [wallet:read, kyc:status. read] }
finance: { allow: [wallet:read, wallet:transfer] }

17）売り上げ前のチェックリスト

PKCE/nonce/stateが有効。PAR/JAR/JARMがアクティブです。
AT/RT/TTL IDセット；RT回転+再利用検出を有効にしました。
敏感なクライアント/操作のためのDPoPまたはmTLSバインディング。
JWKS c 'kid'；自動回転および主消費量の監視。
同意/RARおよびスコープレジストリ；敏感な活動のためのステップアップMFA。
PDP/PEP統合、障害ソリューションキャッシュ。
トークンには'tenant/region/license'が含まれています。レジデンスが観察されます。
Observability：メトリック、ログ、トレース；'invalid_token'、 'rt_reuse'、 'jwks_skew'に警告します。
revoke/rotate/lockdownのPlaybook；緊急ログアウトボタン。
スタンドにE2E/chaos/interopのテストが渡されました。

結論

プラットフォーム機能としてOAuth2/OIDCを組み込むことで、予測可能な承認フロー、マネージドトークン、ユニフォームアクセスポリシー、および測定可能なリスクが得られます。RT、キーローテーション、PAR/JARM/DPoP、同意、ステップアップで保護されたショートATは、セキュリティをデフォルトにし、チームやパートナーにとって迅速かつ痛みのない進化をもたらすプラクティスです。

カーネル内のOAuth2/OpenIDを接続する

結論

お問い合わせ

迅速な連絡

動画はまもなく更新されます

現在、私たちはプロジェクトで非常に多忙です