メインコンテンツへスキップ
従来、Implicit Flow は、シークレットを安全に保存できないアプリケーションで使用されていました。現在では、このフローを使用して を要求することはベストプラクティスとは見なされていません。新規実装では、Authorization Code Flow with PKCE を使用してください。ただし、Form Post レスポンスモードと組み合わせた場合、アプリケーションがユーザー認証のために のみを必要とするのであれば、Implicit Flow は簡略化されたワークフローを提供します。この場合は、Hybrid Flow の一部として使用されます。 認証に Implicit Flow を使用する場合、 は返されなくなります。 さらに、OIDC 準拠パイプラインは、認証リクエスト、認証レスポンス、IDトークンの構造、アクセストークンの構造といった点で Implicit Flow に影響します。

​
認証リクエスト

​
レガシー

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
offline_access スコープを指定してリフレッシュトークンを要求する場合にのみ、device パラメーターが必要です。詳細については、リフレッシュトークンを参照してください。

​
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 を使用する場合、Auth0 は IDトークン のみを返します。 インプリシットグラントではリフレッシュトークンは使用できません。代わりに prompt=none を使用してください。

​
IDトークンの構造

​
レガシー

​
OIDC準拠

  • favorite_color クレームは名前空間付きである必要があり、ルールを使用して追加する必要があります。詳細については、名前空間付きカスタムクレームを作成するを参照してください。
  • IDトークンの検証後、アプリケーションはリプレイ攻撃を防ぐために も検証する必要があります。

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

​
レガシー

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

​
OIDC準拠

  • 返されるアクセストークンは、/userinfo エンドポイントの呼び出しに使用できる です (audience パラメーターで指定された API が 署名アルゴリズム として RS256 を使用している場合) 。また、audience パラメーターで指定されたリソースサーバーの呼び出しにも使用できます。
  • 指定された が /userinfo のみである場合でも、不透明なアクセストークンが返されることがあります。

​
詳しくはこちら