2.2. サポートされている許可タイプ
このセクションでは、リレーパーティーが利用できる様々な許可タイプについて説明します。
2.2.1. 認可コード
認可コードフローは、ユーザーエージェントを Red Hat build of Keycloak にリダイレクトします。Red Hat build of Keycloak でユーザーが正常に認証されると、認可コードが作成され、ユーザーエージェントはアプリケーションにリダイレクトされます。その後、アプリケーションは認証情報と共に認可コードを使用して、Red Hat build of Keycloak からアクセストークン、更新トークン、および ID トークンを取得します。
フローは Web アプリケーションにターゲットとして設定されていますが、ユーザーエージェントを組み込むことができるモバイルアプリケーションなど、ネイティブアプリケーションに推奨されます。
詳細は、OpenID Connect 仕様の Authorization Code Flow を参照してください。
2.2.2. 暗黙的
暗黙的フローは認可コードフローと同じような機能ですが、アクセストークンおよび ID トークンが返される認可コードを返す代わりに、このフローが返されます。このアプローチにより、追加の呼び出しでアクセストークンの認可コードを交換する必要がなくなります。ただし、更新トークンは含まれません。そのため、有効期限の長いアクセストークンを許可する必要があります。しかし、これらのトークンを無効にするのは非常に難しいため、このアプローチは現実的ではありません。あるいは、最初のアクセストークンの有効期限が切れた後、新しいアクセストークンを取得するために新しいリダイレクトを要求できます。暗黙的フローは、アプリケーションがユーザーを認証し、ログアウト自体を処理する場合に便利です。
代わりに、アクセストークンと認可コードの両方が返されるハイブリッドフローを使用できます。
注意すべき点は、アクセストークンが Web サーバーのログやブラウザーの履歴から漏洩する可能性があるため、暗黙的なフローとハイブリッドフローの両方に潜在的なセキュリティーリスクがあることです。アクセストークンの有効期限を短くすることで、この問題をある程度軽減できます。
詳細は、OpenID Connect 仕様の 暗黙的フロー を参照してください。
現在の OAuth 2.0 セキュリティーのベストプラクティス によれば、このフローは使用するべきではありません。このフローは、将来の OAuth 2.1 仕様 から削除されます。
2.2.3. リソースオーナーパスワード認証情報
Red Hat build of Keycloak では Direct Grant と呼ばれるリソース所有者のパスワード認証情報を使用すると、ユーザー認証情報をトークンと交換できます。現在の OAuth 2.0 セキュリティーベストプラクティス によれば、このフローは使用すべきではありません。「デバイス認可グラント」 や 「認可コード」 などの代替方法を推奨します。
このフローの使用には次のような制限があります。
- ユーザーの認証情報ががアプリケーションに公開される
- アプリケーションにはログインページが必要です。
- アプリケーションは認証スキームを認識する必要があります。
- 認証フローへの変更にはアプリケーションへの変更が必要です。
- アイデンティティーブローカーまたはソーシャルログインはサポートされません。
- フロー (ユーザー自己登録、必要なアクションなど) はサポートされません。
このフローのセキュリティー上の懸念点は次のとおりです。
- Red Hat build of Keycloak が認証情報の処理に関与する
- 認証情報の漏洩が発生する可能性のある脆弱な領域が増加する
- ユーザーが認証情報の入力に Red Hat build of Keycloak ではなく別のアプリケーションを信頼するような環境が生まれる
クライアントでリソースオーナーパスワード認証情報の使用を許可するには、クライアントの Direct Access Grants Enabled オプションを有効にする必要があります。
このフローは OpenID Connect に含まれず、OAuth 2.0 仕様の一部です。将来の OAuth 2.1 仕様 からは削除されます。
詳細は、OAuth 2.0 仕様の リソースオーナーパスワード認証情報の付与 の章を参照してください。
2.2.3.1. CURL の使用例
以下の例は、ユーザー名 user およびパスワード password を使用して、レルムの master ユーザーのアクセストークンを取得する方法を示しています。この例では、機密クライアント myclient を使用しています。
curl \ -d "client_id=myclient" \ -d "client_secret=40cc097b-2a57-4c17-b36a-8fdf3fc2d578" \ -d "username=user" \ -d "password=password" \ -d "grant_type=password" \ "http://localhost:8080/realms/master/protocol/openid-connect/token"
2.2.4. クライアントクレデンシャル
クライアント認証情報は、クライアント (アプリケーションおよびサービス) がユーザーの代わりにではなく、自身の代わりにアクセスを取得する場合に使用されます。たとえば、これらの認証情報は、特定のユーザーではなく、一般的なシステムに変更を適用するバックグラウンドサービスなどに役立ちます。
Red Hat build of Keycloak は、クライアントがシークレットまたは公開鍵/秘密鍵のいずれかを使用して認証するためのサポートを提供します。
このフローは OpenID Connect に含まれず、OAuth 2.0 仕様の一部です。
詳細は、OAuth 2.0 仕様の クライアント認証情報の付与 の章を参照してください。
2.2.5. デバイス認可グラント
デバイス認可グラントは、入力機能が制限されているか、適切なブラウザーがないインターネット接続デバイスで実行されているクライアントによって使用されます。
- アプリケーションが、Red Hat build of Keycloak にデバイスコードとユーザーコードを提供するよう要求します。
- Red Hat build of Keycloak が、デバイスコードとユーザーコードを作成します。
- Red Hat build of Keycloak が、デバイスコードおよびユーザーコードなどの応答をアプリケーションに返します。
- アプリケーションが、ユーザーにユーザーコードと検証 URI を提供します。ユーザーは検証 URI にアクセスし、別のブラウザーを使用して認証されます。
- Red Hat build of Keycloak がユーザー認証を完了するまで、アプリケーションが Red Hat build of Keycloak を繰り返しポーリングします。
- ユーザー認証が完了すると、アプリケーションはデバイスコードを取得します。
- アプリケーションは認証情報と共にデバイスコードを使用して、Red Hat build of Keycloak からアクセストークン、更新トークン、および ID トークンを取得します。
詳細は、OAuth 2.0 デバイス認可グラントの仕様 参照してください。
2.2.6. Client Initiated Backchannel Authentication Grant
Client Initiated Backchannel Authentication Grant は、OAuth 2.0 の認可コードグラントのように、ユーザーのブラウザーを介してリダイレクトせずに、OpenID プロバイダーと直接通信することで認可フローを開始するクライアントによって使用されます。
クライアントは、クライアントによる認証要求を識別する auth_req_id を Red Hat build of Keycloak に要求します。Red Hat build of Keycloakは auth_req_id を作成します。
クライアントは、auth_req_id を受信したてからユーザーが認証されるまで、Red Hat build of Keycloak からアクセストークン、更新トークン、および ID トークンを取得するために、auth_req_id と引き換えに Red Hat build of Keycloak を繰り返しポーリングする必要があります。
クライアントが ping モードを使用する場合は、トークンエンドポイントを繰り返しポーリングする必要はありませんが、Red Hat build of Keycloak から指定されたクライアント通知エンドポイントに送信される通知を待つことができます。クライアント通知エンドポイントは、Red Hat build of Keycloak 管理コンソールで設定できます。クライアント通知エンドポイントのコントラクトの詳細は、CIBA 仕様を参照してください。
詳細は、OpenID Connect クライアントが開始したバックチャンネル認証フローの仕様 を参照してください。
また、このガイドの バックチャンネル認証エンドポイント やサーバー管理ガイドの クライアントが開始したバックチャンネル認証グラント セクションなど、Red Hat build of Keycloak ドキュメントの別のパートも参照してください。FAPI CIBA 準拠の詳細は、このガイドの FAPI セクション を参照してください。
