メインコンテンツへスキップ
暗黙フローは従来、シークレットを安全に保存できないアプリケーションで使用されていましたが、このフローの使用はアクセストークンを要求するためのベストプラクティスとはみなされなくなりました。新しい実装では、PKCEを使った認可コードフローを使用してください。ただし、アプリケーションがユーザー認証にIDトークンのみを必要とする場合、フォームPOST応答モードと併用することでワークフローが効率化します。この場合は、ハイブリッドフローの一部として使用します。 認証に暗黙フローを使用すると、リフレッシュトークンは返されなくなります。 さらに、OIDC準拠のパイプラインが認証要求、認証応答、IDトークンの構造、およびアクセストークンの構造の領域で暗黙フローに影響を与えます。

​
認証要求

​
旧

GET /authorize?
    response_type=token
    &scope=openid email favorite_color offline_access
    &client_id=123
    &state=af0ifjsldkj
    &redirect_uri=https://app.example.com
    &device=my-device-name
deviceパラメーターは、offline_accessスコープを渡してリフレッシュトークンを要求する場合にのみ必要です。詳細については、「リフレッシュトークン」をお読みください。

​
OIDC準拠

GET /authorize?
    response_type=token id_token
    &scope=openid email
    &client_id=123
    &state=af0ifjsldkj
    &nonce=jxdlsjfi0fa
    &redirect_uri=https://app.example.com
    &audience=https://api.example.com
  • response_typeは、アクセストークンとIDトークンの両方を受け取りたいことを示します。
  • リフレッシュトークンは暗黙的付与では許可されていません。代わりに、prompt=noneを使用してください。詳細については「サイレント認証を構成する」をお読みください。
  • favorite_colorは有効なスコープでなくなりました。
  • audienceは任意です。
  • nonceは暗号学的に安全なランダム文字列でなければなりません。詳細については、「暗黙フロー使用時にリプレイ攻撃を軽減する」をお読みください。

​
認証応答

​
旧

HTTP/1.1 302 Found
Location: https://app.example.com/#
    access_token=SlAV32hkKG
    &expires_in=86400
    &state=af0ifjsldk
    &id_token=eyJ...
    &refresh_token=8xLOxBtZp8
    &token_type=Bearer
  • 返されるアクセストークンは、/userinfoエンドポイントの呼び出しに対して有効です。
  • リフレッシュトークンは、deviceパラメーターが渡され、offline_accessスコープが要求された場合にのみ返されます。

​
OIDC準拠

HTTP/1.1 302 Found
Location: https://app.example.com/#
    access_token=eyJ...
    &expires_in=86400
    &state=af0ifjsldk
    &id_token=eyJ...
    &token_type=Bearer
  • 返されるアクセストークンは、/userinfoエンドポイント（audienceパラメーターで指定したAPIがRS256を署名アルゴリズムとして使用していることを条件とする）と、audienceパラメーターで指定したリソースサーバー（任意）の呼び出しに対してのみ有効です。
  • response_type=id_tokenを使用する場合は、IDトークンのみが返されます。リフレッシュトークンは暗黙的付与では許可されていません。代わりに、prompt=noneを使用してください。

​
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",
    "nonce": "jxdlsjfi0fa"
}
  • favorite_colorクレームには名前空間が存在し、ルールを通じて追加される必要があります。詳細については、「名前空間カスタムクレームを作成する」をお読みください。
  • IDトークンを検証したら、アプリケーションはリプレイ攻撃を軽減するためにを検証する必要があります。

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

​
旧

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"
}
  • 返されるアクセストークンは、/userinfo（audienceパラメーターで指定したAPIがRS256を署名アルゴリズムとして使用していることを条件とする）と、audienceパラメーターで指定したリソースサーバーの呼び出しに対してのみ有効です。
  • /userinfoが唯一指定されたオーディエンスである場合でも、不透明なアクセストークンが返されることがあります。

​
もっと詳しく

⌘I