メインコンテンツへスキップ
認可コードフローは、シークレットを安全に保存できるサーバー側アプリケーション、またはネイティブアプリケーションが、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

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

認可コードは両方のパイプラインで同じ方法で交換できます。 
curl --request POST \
  --url 'https://{yourDomain}/oauth/token' \
  --header 'content-type: application/x-www-form-urlencoded' \
  --data grant_type=authorization_code \
  --data 'client_id={yourClientId}' \
  --data client_secret=YOUR_CLIENT_SECRET \
  --data code=YOUR_AUTHORIZATION_CODE \
  --data 'redirect_uri={https://yourApp/callback}'

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

認可コードは両方のパイプラインで同じ方法で交換できます。 
curl --request POST \
  --url 'https://{yourDomain}/oauth/token' \
  --header 'content-type: application/x-www-form-urlencoded' \
  --data grant_type=authorization_code \
  --data 'client_id={yourClientId}' \
  --data code_verifier=YOUR_GENERATED_CODE_VERIFIER \
  --data code=YOUR_AUTHORIZATION_CODE \
  --data 'redirect_uri={https://yourApp/callback}'

​
コード交換応答

​
旧

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トークンの構造

​
旧

JSON
{
    "sub": "auth0|alice",
    "iss": "https://{yourDomain}/",
    "aud": "123",
    "exp": 1482809609,
    "iat": 1482773609,
    "email": "alice@example.com",
    "email_verified": true,
    "favorite_color": "blue"
}

​
OIDC準拠

JSON
{
    "sub": "auth0|alice",
    "iss": "https://{yourDomain}/",
    "aud": "123",
    "exp": 1482809609,
    "iat": 1482773609,
    "email": "alice@example.com",
    "email_verified": true,
    "https://app.example.com/favorite_color": "blue"
}
favorite_colorクレームはAuth0アクションを通じて追加する必要があります。詳細については、「カスタムクレームを作成する」をお読みください。

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

​
旧

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

​
OIDC準拠

JSON
{
    "sub": "auth0|alice",
    "iss": "https://{yourDomain}/",
    "aud": [
        "https://api.example.com",
        "https://{yourDomain}/userinfo"
    ],
    "azp": "123",
    "exp": 1482816809,
    "iat": 1482809609,
    "scope": "openid email"
}
返されるアクセストークンは、audienceパラメーターおよび/userinfoエンドポイントで指定されたAPIの呼び出しに対してオプションで有効です（APIが署名アルゴリズムとしてRS256を使用し、openidがscopeパラメーターとして使用されている場合）。 独自のリソースサーバー（API）を実装していない場合、https://{$account.namespace}/userinfoをaudienceパラメーターとして使用でき、これは不透明なアクセストークンを返します。

​
もっと詳しく

⌘I