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

認可

前提知識​

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

概要​

idp-serverは、OAuth 2.0/OpenID Connect/CIBAに準拠した認可サーバー（Authorization Server） として動作します。

認可サーバーとは、リソースへのアクセス権限を管理し、トークンを発行する役割を担うサーバーです。

idp-serverでは以下のような用途に対応できます：

  • Webアプリケーションでの「スコープ制限付きアクセス」
  • SPAでの「安全なトークン管理（PKCE + Refresh Token Rotation）」
  • マイクロサービスでの「サービス間認証（Client Credentials Grant）」
  • IoTデバイスでの「非同期認証（CIBA Flow）」

OAuth 2.0における4つの役割​

役割説明idp-serverでの対応
Resource Ownerリソースの所有者（エンドユーザー）idp-serverで認証・同意
ClientリソースにアクセスしたいアプリケーションManagement APIで登録・管理
Authorization Server認可を管理し、トークンを発行idp-server本体
Resource Server保護されたリソース（API）を提供Introspectionでトークン検証

idp-serverにおける認可の設計思想​

1. テナント単位の認可サーバー​

idp-serverでは、1つのテナント = 1つの独立した認可サーバー として動作します。

特徴:

  • テナントごとに異なる認可ポリシー
  • テナントごとに独立したクライアント管理
  • テナントごとに異なるトークン設定

メリット:

  • マルチテナント環境での完全な分離
  • テナントごとのカスタマイズ可能
  • セキュリティ境界の明確化

詳細は concept-01: マルチテナント を参照。

2. スコープベースのアクセス制御​

idp-serverでは、スコープ（Scope） を単位としてアクセス権限を管理します。

スコープの種類:

スコープタイプ例用途
標準スコープopenid, profile, emailOIDC標準のユーザー属性
カスタムスコープapi:read, api:write独自API権限
カスタムクレームスコープclaims:roles, claims:permissions個別属性指定（idp-server独自）
身元確認スコープverified_claims:given_name身元確認済み属性（idp-server独自）

設計原則:

  • 最小権限の原則: 必要最小限のスコープのみ付与
  • 粒度の適切さ: 粗すぎず細かすぎない権限設計
  • 認証強度との連動: 強い認証 = より多くのスコープ許可（動的スコープフィルタリング）

詳細は concept-09: カスタムクレーム を参照。

3. 認証強度と連動した動的スコープフィルタリング​

idp-server独自の機能として、認証方式に応じてスコープを動的に制限できます。

使用例:

パスワード認証のみ → scope=openid profile（基本情報のみ）
FIDO2認証 → scope=openid verified_claims:*（身元確認済み情報も許可）

メリット:

  • 認証強度に応じた適切な情報開示
  • 過剰な権限付与の防止
  • セキュリティとユーザー体験の両立

詳細は concept-05: 認証ポリシー を参照。

4. 身元確認との連携​

verified_claims: スコープにより、身元確認済み属性のみを取得できます。

使用例:

scope=openid verified_claims:given_name verified_claims:family_name

→ 身元確認済みの名前のみを取得

条件:

  • ユーザーが身元確認（eKYC）を完了していること
  • verified_claims: プレフィックス付きスコープを要求
  • 認証強度が要件を満たしていること

詳細は concept-03: 身元確認済みID を参照。

5. 多様な認可フロー​

idp-serverは、クライアントの特性に応じた複数の認可フローをサポートします。

フロー選択の基準:

クライアント種類推奨フロー理由
サーバーサイドWebアプリAuthorization Code Flow最も安全、シークレット保護可能
SPA/モバイルアプリAuthorization Code + PKCEPublic Clientでも安全
マイクロサービス（M2M）Client Credentials Grantユーザー不要の認可
IoT/デバイス認証CIBA Flow非同期・プッシュ通知対応

詳細は以下を参照：

6. クライアント認証の柔軟性​

idp-serverは、7つのクライアント認証方式をサポートします。

認証方式の選択基準:

選択基準推奨方式理由
FAPI準拠（金融・医療）tls_client_authMutual TLS、FAPI要件
シークレット共有を避けたいprivate_key_jwt公開鍵暗号、漏洩リスク低
シークレット共有OKclient_secret_basic/postシンプル、管理容易
Public Clientnone + PKCESPA/モバイルアプリ

7. 2種類のトークン形式​

idp-serverは、2種類のトークン形式をサポートします。

識別子型（Opaque Token）:

アクセストークン: "7b3f8c2d-9e1a-4f6b-8d2c-1a3e5f7b9d2c"
→ データベースで検証・管理
→ Introspectionで検証
→ 即座に失効可能

内包型（JWT Token）:

アクセストークン: "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9..."
→ 署名検証のみで利用可能
→ データベースアクセス不要
→ 失効は有効期限まで不可（リボケーションリストで対応）

比較:

特性識別子型内包型（JWT）
検証方法Introspection API署名検証
即座の失効可能不可（リボケーションリストで対応）
パフォーマンスDB問い合わせ必要署名検証のみ
推奨用途厳密な制御が必要な場合高速・スケーラブル

詳細は concept-06: トークン管理 を参照。

ユースケース​

1. Webアプリケーションでのユーザー認証・認可​

シーン: SaaSサービスのWebアプリで、ユーザーのプロフィール情報を取得したい

設定:

  • クライアントタイプ: Confidential Client
  • 認可フロー: Authorization Code Flow
  • クライアント認証: private_key_jwt
  • スコープ: openid profile email
  • トークン形式: 内包型（JWT）

フロー:

  1. ユーザーがWebアプリにアクセス
  2. Webアプリがidp-serverにリダイレクト
  3. ユーザーが認証・同意
  4. 認可コード発行
  5. Webアプリがトークンエンドポイントでトークン取得
  6. IDトークンからユーザー情報取得

2. SPAでの認証・認可​

シーン: React/VueのSPAで、安全にユーザー認証したい

設定:

  • クライアントタイプ: Public Client
  • 認可フロー: Authorization Code Flow + PKCE
  • クライアント認証: none
  • スコープ: openid profile
  • トークン形式: Refresh Token Rotation有効化

セキュリティ対策:

  • PKCE必須（code_verifier/code_challenge）
  • Refresh Token Rotation（使い捨てトークン）
  • 短いアクセストークン有効期限（15分以内推奨）

3. マイクロサービスでのAPI保護​

シーン: マイクロサービス間通信で、サービスAがサービスBのAPIにアクセスしたい

設定:

  • クライアントタイプ: Confidential Client
  • 認可フロー: Client Credentials Grant
  • クライアント認証: private_key_jwt
  • スコープ: api:read api:write
  • トークン検証: Introspection

フロー:

  1. サービスAが Client Credentials Grant でトークン取得
  2. サービスAがトークンを付けてサービスBにリクエスト
  3. サービスBがIntrospectionでトークン検証
  4. スコープ確認（api:readがある？）
  5. レスポンス返却

4. モバイルアプリでのデバイス認証​

シーン: モバイルアプリで、プッシュ通知による認証を実現したい

設定:

  • クライアントタイプ: Confidential Client
  • 認可フロー: CIBA Flow (Push Mode)
  • クライアント認証: private_key_jwt
  • スコープ: openid profile verified_claims:*
  • 認証デバイス: FCM Push通知

フロー:

  1. クライアントがバックチャネル認証リクエスト
  2. idp-serverがユーザーのデバイスにプッシュ通知
  3. ユーザーがデバイスで認証・承認
  4. idp-serverがクライアントにPush通知（認証完了）
  5. クライアントがトークンエンドポイントでトークン取得

詳細は protocol-02: CIBA Flow を参照。

セキュリティ考慮事項​

認可サーバー側の責務​

  • クライアント検証: リダイレクトURIの厳密な一致検証
  • PKCE強制: Public Clientは必ずPKCE使用
  • トークン有効期限: 適切な短期設定（Access Token: 15分、Refresh Token: 30日等）
  • 同意の記録: ユーザーの同意履歴を永続化
  • 監査ログ: すべての認可操作をログ記録（concept-11参照）

クライアント側の責務​

  • ステート検証: CSRF対策（stateパラメータ）
  • PKCE実装: Public Clientは必須
  • トークン保護: セキュアな保存（HTTPOnly Cookie、Secure Storage等）
  • スコープ最小化: 必要最小限のスコープのみ要求

スコープ設計の原則​

  • 最小権限: 必要な情報だけアクセス
  • 粒度の適切さ: adminのような粗すぎるスコープは避ける
  • センシティブ情報: verified_claims等は慎重に扱う
  • 認証強度連動: 弱い認証では強いスコープを許可しない

セキュリティ拡張機能​

idp-serverは、最新のOAuth/OIDCセキュリティ拡張をサポートします。

拡張仕様仕様目的idp-server対応
PKCERFC 7636認可コード横取り攻撃対策✅ 必須（Public Client）
JARRFC 9101認可リクエストのJWT化✅ 対応
JARMOIDF JARM認可レスポンスのJWT化✅ 対応
PARRFC 9126認可リクエストの事前プッシュ✅ 対応
RARRFC 9396詳細なアクセス要求✅ 対応
FAPIOIDF FAPI 1.0/2.0金融レベルセキュリティ✅ Baseline/Advanced対応

これらの拡張により、金融・医療・行政など高セキュリティ要件の環境でも利用可能です。

関連ドキュメント​

参考仕様​