OIDCにおける認可コードフロー

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

認可コードフロー は、シークレットを安全に保存できるサーバーサイドのアプリケーション、またはネイティブアプリケーションで PKCE を使用した Authorization Code フロー を利用する場合に使用されます。

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 スコープを指定して リフレッシュトークン をリクエストする場合のみです。詳しくは、Refresh Tokens をご覧ください。

​

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 は有効な scope 値ではなくなりました。
• device パラメーターは削除されました。
• audience パラメーターは省略可能です。

​

認証レスポンス

Auth0からのレスポンスは、どちらのパイプラインでも同じです。

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

​

コード交換リクエスト - 認可コードフロー

どちらのパイプラインでも、認可コードの交換方法は同じです:

​

コード交換リクエスト - PKCE を使用した Authorization Code フロー

認可コードの交換方法は、どちらのパイプラインでも同じです:

​

コード交換のレスポンス

​

レガシー

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 パラメーターで指定された API と /userinfo エンドポイントの呼び出しに使用できます (ただし、その API が 署名アルゴリズム として RS256 を使用し、scope パラメーターに openid が含まれている場合に限ります) 。独自の リソースサーバー (API) を実装していない場合は、audience パラメーターとして https://{$account.namespace}/userinfo を使用できます。この場合、オペークなアクセストークンが返されます。
• リフレッシュトークンが返されるのは、offline_access scope がグラントされた場合のみです。

​

ID トークンの構造

​

レガシー

​

OIDC準拠

favorite_color クレームは、Auth0 Action を使用して追加する必要があります。詳しくは、カスタムクレームを作成するをご覧ください。

​

アクセストークンの構造 (任意)

​

レガシー

HTTP

SlAV32hkKG

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

​

OIDC準拠

返されたアクセストークンは、必要に応じて audience パラメーターで指定した API および /userinfo エンドポイントの呼び出しに使用できます (ただし、その API が 署名アルゴリズム として RS256 を使用し、scope パラメーターに openid を指定している場合に限ります) 。

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

​

詳しくはこちら

• OIDCによるアクセストークン
• OIDCによる外部API
• OIDCによるクライアント認証情報フロー
• OIDCによるインプリシットフロー
• OIDCによるリフレッシュトークン
• OIDCによるリソース所有者パスワードフロー