OIDC の Implicit Flow

Auth0 の OIDC 準拠パイプラインが Implicit Flow の動作をどのように変更し、トークン処理を妨げることなく既存のアプリケーションを更新する方法について学びます。

従来、Implicit Flow は、シークレットを安全に保存できないアプリケーションで使用されていました。アクセストークン を要求するためにこのフローを使用することは、もはやベストプラクティスとは見なされていません。新規実装では、PKCE を使用した Authorization Code フロー を使用してください。ただし、Form Post レスポンスモードと組み合わせる場合、アプリケーションがユーザー認証を行うために ID トークン だけを必要とするのであれば、Implicit Flow はよりシンプルなワークフローを実現できます。このような場合は、Hybrid Flow の一部として使用されます。

リフレッシュトークン は、認証に Implicit Flow を使用した場合、返されなくなります。

さらに、OIDC 準拠のパイプラインは、次の領域で Implicit Flow に影響します: 認証リクエスト、認証レスポンス、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

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 には、暗号学的に安全なランダム文字列を指定する必要があります。詳しくは、Implicit Flow の使用時にリプレイ攻撃を軽減する を参照してください。

​

認証レスポンス

​

レガシー

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 が、signing algorithmとして RS256 を使用している場合) 。また、必要に応じて audience パラメータで指定されたリソースサーバーに対しても有効です。
• response_type=id_token を使用する場合、Auth0 は ID トークンのみを返します。 リフレッシュトークンは インプリシットグラント では使用できません。代わりに prompt=none を使用してください。

​

ID トークンの構造

​

レガシー

​

OIDC準拠

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

​

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

​

レガシー

HTTP

SlAV32hkKG

返されたアクセストークンはオペークで、/userinfo エンドポイントの呼び出しにのみ有効です。

​

OIDC準拠

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

​

詳しくはこちら

• OIDC を使用したアクセストークン
• OIDC を使用した外部 API
• OIDC を使用した認可コードフロー
• OIDC を使用したクライアント認証情報フロー
• OIDC を使用した委譲
• OIDC を使用したリフレッシュトークン