OIDCを使った認可コードフロー

OIDC準拠のパイプラインが認可コードフローにどのような影響を与えるのかについて説明します。

認可コードフローは、シークレットを安全に保存できるサーバー側アプリケーション、またはネイティブアプリケーションが、PKCEを使った認可コードフローを介して使用します。

OIDC準拠のパイプラインが認可コードフローに影響を与える領域は以下のとおりです。

• 認証要求
• 認証応答
• コード交換要求
• コード交換応答
• IDトークンの構造
• アクセストークンの構造

​

認証要求

​

旧

GET /authorize?
    response_type=code
    &scope=openid email favorite_color offline_access
    &client_id=123
    &state=af0ifjsldkj
    &redirect_uri=https://app.example.com/callback
    &device=my-device-name

deviceパラメーターは、offline_accessスコープを渡してリフレッシュトークンを要求する場合にのみ必要です。詳細については、「リフレッシュトークン」をお読みください。

​

OIDC準拠

GET /authorize?
    response_type=code
    &scope=openid email offline_access
    &client_id=123
    &state=af0ifjsldkj
    &redirect_uri=https://app.example.com/callback
    &audience=https://api.example.com

• favorite_colorは有効なスコープ値ではなくなりました。
• deviceパラメーターは削除されています。
• audienceパラメーターは任意です。

​

認証応答

Auth0からの応答は両方のパイプラインで同じです。

HTTP/1.1 302 Found
Location: https://app.example.com/callback?
    code=SplxlOBeZQQYbYS6WxSbIA
    &state=af0ifjsldkj

​

コード交換要求 - 認可コードフロー

認可コードは両方のパイプラインで同じ方法で交換できます。

​

コード交換要求 - PKCEを使った認可コードフロー

認可コードは両方のパイプラインで同じ方法で交換できます。

​

コード交換応答

​

旧

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..."
}

• 返されるアクセストークンは、/userinfoエンドポイントの呼び出しに対してのみ有効です。
• リフレッシュトークンは、deviceパラメーターが渡され、offline_accessスコープが要求された場合にのみ返されます。

​

OIDC準拠

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
    "access_token": "eyJ...",
    "token_type": "Bearer",
    "refresh_token": "8xLOxBtZp8",
    "expires_in": 3600,
    "id_token": "eyJ..."
}

• 返されるアクセストークンは、audienceパラメーターおよび/userinfoエンドポイントで指定されたAPIの呼び出しに対してオプションで有効です（APIが署名アルゴリズムとしてRS256を使用し、openidがscopeパラメーターとして使用されている場合）。独自のリソースサーバー（API）を実装していない場合、https://{$account.namespace}/userinfoをaudienceパラメーターとして使用でき、これは不透明なアクセストークンを返します。
• リフレッシュトークンは、offline_accessスコープが付与された場合にのみ返されます。

​

IDトークンの構造

​

旧

​

OIDC準拠

favorite_colorクレームはAuth0アクションを通じて追加する必要があります。詳細については、「カスタムクレームを作成する」をお読みください。

​

アクセストークンの構造（任意）

​

旧

HTTP

SlAV32hkKG

返されるアクセストークンは不透明で、/userinfoエンドポイントの呼び出しに対してのみ有効です。

​

OIDC準拠

返されるアクセストークンは、audienceパラメーターおよび/userinfoエンドポイントで指定されたAPIの呼び出しに対してオプションで有効です（APIが署名アルゴリズムとしてRS256を使用し、openidがscopeパラメーターとして使用されている場合）。

独自のリソースサーバー（API）を実装していない場合、https://{$account.namespace}/userinfoをaudienceパラメーターとして使用でき、これは不透明なアクセストークンを返します。

​

もっと詳しく

• OIDCにおけるアクセストークン
• OIDCを持つ外部API
• OIDCを使用したクライアントの資格情報フロー
• OIDCを使った暗黙フロー
• OIDCにおけるリフレッシュトークン
• OIDCでのリソース所有者のパスワードフロー