2.2. サポートされている許可タイプ

認可コードフローは、ユーザーエージェントを Red Hat build of Keycloak にリダイレクトします。Red Hat build of Keycloak でユーザーが正常に認証されると、認可コードが作成され、ユーザーエージェントはアプリケーションにリダイレクトされます。その後、アプリケーションは認証情報と共に認可コードを使用して、Red Hat build of Keycloak からアクセストークン、更新トークン、および ID トークンを取得します。

フローは Web アプリケーションにターゲットとして設定されていますが、ユーザーエージェントを組み込むことができるモバイルアプリケーションなど、ネイティブアプリケーションに推奨されます。

詳細は、OpenID Connect 仕様の Authorization Code Flow を参照してください。

暗黙的フローは認可コードフローと同じような機能ですが、アクセストークンおよび ID トークンが返される認可コードを返す代わりに、このフローが返されます。このアプローチにより、追加の呼び出しでアクセストークンの認可コードを交換する必要がなくなります。ただし、更新トークンは含まれません。そのため、有効期限の長いアクセストークンを許可する必要があります。しかし、これらのトークンを無効にするのは非常に難しいため、このアプローチは現実的ではありません。あるいは、最初のアクセストークンの有効期限が切れた後、新しいアクセストークンを取得するために新しいリダイレクトを要求できます。暗黙的フローは、アプリケーションがユーザーを認証し、ログアウト自体を処理する場合に便利です。

代わりに、アクセストークンと認可コードの両方が返されるハイブリッドフローを使用できます。

注意すべき点は、アクセストークンが Web サーバーのログやブラウザーの履歴から漏洩する可能性があるため、暗黙的なフローとハイブリッドフローの両方に潜在的なセキュリティーリスクがあることです。アクセストークンの有効期限を短くすることで、この問題をある程度軽減できます。

詳細は、OpenID Connect 仕様の 暗黙的フロー を参照してください。

Red Hat build of Keycloak では Direct Grant と呼ばれるリソース所有者のパスワード認証情報を使用すると、ユーザー認証情報をトークンと交換できます。必須でない限り、このフローの使用は推奨できません。このフローは、従来のアプリケーションおよびコマンドラインインターフェイスなどで役に立ちます。

このフローの使用には次のような制限があります。

クライアントでリソースオーナーパスワード認証情報の使用を許可するには、クライアントの Direct Access Grants Enabled オプションを有効にする必要があります。

このフローは OpenID Connect に含まれず、OAuth 2.0 仕様の一部です。

詳細は、OAuth 2.0 仕様の リソースオーナーパスワード認証情報の付与 の章を参照してください。

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"

クライアント認証情報は、クライアント (アプリケーションおよびサービス) がユーザーの代わりにではなく、自身の代わりにアクセスを取得する場合に使用されます。たとえば、これらの認証情報は、特定のユーザーではなく、一般的なシステムに変更を適用するバックグラウンドサービスなどに役立ちます。

Red Hat build of Keycloak は、クライアントがシークレットまたは公開鍵/秘密鍵のいずれかを使用して認証するためのサポートを提供します。

このフローは OpenID Connect に含まれず、OAuth 2.0 仕様の一部です。

詳細は、OAuth 2.0 仕様の クライアント認証情報の付与 の章を参照してください。

デバイス認可グラントは、入力機能が制限されているか、適切なブラウザーがないインターネット接続デバイスで実行されているクライアントによって使用されます。アプリケーションは、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 デバイス認可グラントの仕様 参照してください。

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 セクション を参照してください。