2.4. その他の OpenID Connect ライブラリー

/realms/{realm-name}/protocol/openid-connect/auth

/realms/{realm-name}/protocol/openid-connect/auth

認可エンドポイントはエンドユーザーの認証を実行します。これは、ユーザーエージェントをこのエンドポイントにリダイレクトすることで行います。

詳細は、OpenID Connect 仕様の 認可エンドポイント セクションを参照してください。

/realms/{realm-name}/protocol/openid-connect/token

/realms/{realm-name}/protocol/openid-connect/token

トークンエンドポイントは、トークンの取得に使用されます。トークンは、認可コードを調べるか、使用するフローに応じて認証情報を直接指定して取得できます。トークンエンドポイントは、有効期限が切れたときに新しいアクセストークンの取得にも使用されます。

詳細は、OpenID Connect 仕様の トークンエンドポイント セクションを参照してください。

/realms/{realm-name}/protocol/openid-connect/userinfo

/realms/{realm-name}/protocol/openid-connect/userinfo

userinfo エンドポイントは、認証されたユーザーについての標準要求を返し、ベアラートークンによって保護されます。

詳細は、OpenID Connect 仕様の userInfo エンドポイント セクションを参照してください。

/realms/{realm-name}/protocol/openid-connect/logout

/realms/{realm-name}/protocol/openid-connect/logout

ログアウトエンドポイントは、認証されたユーザーをログアウトします。

ユーザーエージェントはエンドポイントにリダイレクトできます。この場合は、アクティブなユーザーセッションがログアウトされます。その後、ユーザーエージェントはアプリケーションにリダイレクトされます。

エンドポイントはアプリケーションによって直接呼び出すこともできます。このエンドポイントを直接呼び出すには、更新トークンとクライアントの認証に必要な認証情報を追加する必要があります。

/realms/{realm-name}/protocol/openid-connect/certs

/realms/{realm-name}/protocol/openid-connect/certs

証明書エンドポイントは、レルムが有効にした公開鍵を返し、JSON Web Key (JWK) としてエンコードされます。レルム設定によっては、トークンの検証に 1 つ以上のキーが有効になります。詳細は、Server Administration Guide および JSON Web Key 仕様 を参照してください。

/realms/{realm-name}/protocol/openid-connect/token/introspect

/realms/{realm-name}/protocol/openid-connect/token/introspect

イントロスペクションエンドポイントは、トークンのアクティブな状態を取得するために使用されます。つまり、これを使用してアクセストークンを検証したり、更新したりできます。これは、機密クライアントでのみ呼び出すことができます。

このエンドポイントで呼び出す方法の詳細については、OAuth 2.0 Token Introspection specification を参照してください。

/realms/{realm-name}/clients-registrations/openid-connect

/realms/{realm-name}/clients-registrations/openid-connect

動的クライアント登録エンドポイントは、クライアントを動的に登録するのに使用されます。

詳細は、クライアント登録 および OpenID 接続動的クライアント登録仕様 の章を参照してください。

/realms/{realm-name}/protocol/openid-connect/revoke

/realms/{realm-name}/protocol/openid-connect/revoke

トークン失効エンドポイントは、トークンの取り消しに使用されます。このエンドポイントでは、更新トークンとアクセストークンの両方がサポートされます。

このエンドポイントで呼び出す方法の詳細については、OAuth 2.0 Token Revocation specification を参照してください。

/realms/{realm-name}/protocol/openid-connect/auth/device

/realms/{realm-name}/protocol/openid-connect/auth/device

デバイス認可エンドポイントは、デバイスコードとユーザーコードを取得するために使用されます。これは、機密またはパブリッククライアントで呼び出すことができます。

このエンドポイントで呼び出す方法の詳細については、OAuth 2.0 Device Authorization Grant specification を参照してください。

/realms/{realm-name}/protocol/openid-connect/ext/ciba/auth

/realms/{realm-name}/protocol/openid-connect/ext/ciba/auth

backchannel 認証エンドポイントは、クライアントによる認証要求を識別する auth_req_id を取得するために使用されます。これは、機密クライアントでのみ呼び出すことができます。

このエンドポイントで呼び出す方法の詳細は、OpenID Connect Client Initiated Backchannel Authentication Flow specification を参照してください。

また、本書の Client Initiated Backchannel Authentication Grant セクションおよび Server Administration Guide の Client Initiated Backchannel Authentication Grant セクションなど、Red Hat Single Sign-On ドキュメントの他の部分についても参照してください。

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

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

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

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

また、アクセストークンと認可コードの両方が返されるハイブリッドフローもあります。

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

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

Red Hat Single Sign-On の Direct Grant (Direct Grant) と呼ばれるリソースオーナーパスワード認証情報を使用すると、ユーザー認証情報をトークンと交換できます。絶対に必要な場合を除き、このフローの使用は推奨されません。これは、従来のアプリケーションおよびコマンドラインインターフェイスなどで役に立ちます。

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

クライアントで Resource Owner Password Credentials の使用を許可するには、クライアントに Direct Access Grants Enabled オプションを有効にする必要があります。

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

詳細は、OAuth 2.0 仕様の Resource Owner Password Credentials Grant の章を参照してください。

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/auth/realms/master/protocol/openid-connect/token"

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/auth/realms/master/protocol/openid-connect/token"

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

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

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

詳細は、OAuth 2.0 仕様の Client Credentials Grant の章を参照してください。

Device Authorization Grant は、入力機能が制限されているか、適切なブラウザーがないインターネット接続デバイスで実行されているクライアントによって使用されます。アプリケーションは Red Hat Single Sign-On にデバイスコードとユーザーコードを要求します。Red Hat Single Sign-On は、デバイスコードとユーザーコードを作成します。Red Hat Single Sign-On は、デバイスコードおよびユーザーコードなどの応答をアプリケーションに返します。次に、アプリケーションはユーザーにユーザーコードと検証 URI を提供します。ユーザーは検証 URI にアクセスし、別のブラウザーを使用して認証されます。アプリケーションは、Red Hat Single Sign-On がユーザー認可を完了するまで、Red Hat Single Sign-On を繰り返しポーリングします。ユーザー認証が完了すると、アプリケーションはデバイスコードを取得します。その後、アプリケーションは認証情報と共にデバイスコードを使用して、Red Hat Single Sign-On からアクセストークン、更新トークン、および ID トークンを取得します。

詳細は、OAuth 2.0 Device Authorization Grant specification を参照してください。

Client Initiated Backchannel Authentication Grant は、OAuth 2.0 の認可コード付与のように、ユーザーのブラウザーを介してリダイレクトせずに、OpenID プロバイダーと直接通信することで認可フローを開始するクライアントによって使用されます。

クライアントは、クライアントによる認証要求を識別する auth_req_id を Red Hat Single Sign-On に要求します。Red Hat Single Sign-On は auth_req_id を作成します。

この auth_req_id を受信した後、このクライアントは、ユーザーが認証されるまで、auth_req_id と引き換えに、Red Hat Single Sign-On からアクセストークン、更新トークン、および ID トークンを取得するために Red Hat Single Sign-On を繰り返しポーリングする必要があります。

クライアントが ping モードを使用する場合は、トークンエンドポイントを繰り返しポーリングする必要はありませんが、Red Hat Single Sign-On から指定された Client Notification Endpoint に送信される通知を待つことができます。Client Notification Endpoint は、Red Hat Single Sign-On 管理コンソールで設定できます。Client Notification Endpoint のコントラクトの詳細は、CIBA 仕様を参照してください。

詳細は、OpenID Connect Client Initiated Backchannel Authentication Flow specification を参照してください。

また、本書の backchannel 認証エンドポイント およびサーバー管理ガイドの Client Initiated Backchannel Authentication Grant セクションなど、Red Hat Single Sign-On ドキュメントの別の部分についても参照してください。FAPI CIBA コンプライアンスの詳細は、本書の FAPI セクションを参照してください。