OpenID Connect のトークン・エンドポイントの起動
OpenID Connect Authorization Code Flow では、ID トークン、アクセス・トークン、およびリフレッシュ・トークンを取得するために、 クライアントによってトークン・エンドポイントが使用されます。
始める前に
このタスクについて
トークン・エンドポイントは、認可エンドポイントによってクライアントに発行される認可コードを含んでいる、 クライアントからの要求を受け入れます。その認可コードが検証されると、 適切なトークンが応答に入れられてクライアントに返されます。
OpenID Connect Implicit Flow ではトークン・エンドポイントは使用されません。
OpenID Connect が有効になった Liberty サーバーは、 以下の URL で OpenID Connect トークン・エンドポイントにアクセスできます。
https://server.example.com:443/oidc/endpoint/<provider_name>/token
OpenID Connect プロバイダー (OP) へのアクセスにプロキシーを使用する必要がある場合は、OP 関連の URL プロパティーに入力する値には、外部 OP のホストおよびポートではなく、プロキシーのホストおよびポートが含まれる必要があります。
ほとんどの場合、OP のホストおよびポートを、プロキシーのホストおよびポートに置き換えることができます。入力する URL は、RP およびクライアント (ブラウザーまたはアプリケーション) の両方に可視でなければなりません。使用する正しい URL を決定する方法について詳しくは、プロキシー管理者にお問い合わせください。
この例では、クライアントは SSL ポートが 443 に設定されると予期しています。
手順
タスクの結果
OpenID Connect プロバイダーは、 クライアントから受信したトークン要求を検証すると、application/json フォーマットの JSON オブジェクトとともに HTTP 200 応答をクライアントに返します。 応答には、ID トークン、アクセス・トークン、およびリフレッシュ・トークンが、以下の追加パラメーターとともに含まれます。
- token_type: OAuth 2.0 トークン・タイプ。OpenID Connect では、この値は Bearer です。
- expires_in: 応答が生成されてからのアクセス・トークンの有効期限 (秒単位)。
トークン、秘密、または他の機密情報を含んでいる、トークン・エンドポイントからのすべての応答では、 Cache-Control ヘッダー値は no-store に、Pragma ヘッダー値は no-cache に設定されます。
.例
要求例は次のとおりです。
POST /token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
grant_type=authorization_code
&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
応答例は次のとおりです。
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"access_token": "SlAV32hkKG",
"token_type": "Bearer",
"refresh_token": "8xLOxBtZp8",
"expires_in": 3600,
"id_token": "eyJ ... zcifQ.ewo ... NzAKfQ.ggW8h ... Mzqg"
}