Skip to main content
「implicit」という名称に惑わされないでください。OAuth では現在、SPA でアクセストークンを取得するための Implicit grant の使用は推奨されていませんが、Form Post を使用する Implicit Flow が対象とするシナリオはそれとはまったく異なり、SPA での利用が非推奨になった原因であるセキュリティ上の問題の影響を受けません。具体的には、Form Post を使用する Implicit Flow は SPA ではなく従来型の Web アプリに適用されます。取得するのはアクセストークンではなく ID トークンであり、その用途もまったく異なります。また、このフローではトークンを URL フラグメントに含める方式 (SPA の場合) ではなく POST を使用するため、ブラウザー履歴への攻撃やリダイレクトヘッダーなどを通じてトークンの一部が露出するリスクを避けられます。
従来型の Web アプリでのサインインは、 Connect (OIDC) のさまざまなフローを使って実現できます。一般的なフローの 1 つでは、アプリのバックエンドで実行される認可コードフローを使って を取得します。この方法は効果的で堅牢ですが、Web アプリでシークレットを取得して管理する必要があります。必要なのがサインインの実装だけで、API を呼び出すための を取得する必要がないのであれば、その負担は避けられます。 Form Post を使用する Implicit Flow では、 や WS-Federation と非常によく似た方法で、OIDC を使って Web サインインを実装します。Web アプリはシークレットや追加のバックエンド呼び出しを必要とせず、フロントチャネル経由でトークンを要求し、取得できます。この方法であれば、アプリケーション内でシークレットを取得、維持、使用、保護する必要はありません。

​
仕組み

このフローは、ログインのみのユースケースで使用してください。ユーザーのログイン時に API を呼び出すためのアクセストークンもリクエストする必要がある場合は、PKCE を使用した Authorization Code フロー または Hybrid Flow を使用してください。
Flows - form_post を使用した Implicit - 認可シーケンス図
  1. ユーザーがアプリで Login をクリックします。
  2. Auth0 の SDK は、要求する認証情報の種類を示す response_type パラメータ id_token を付けて、ユーザーを Auth0 Authorization Server (/authorize エンドポイント) にリダイレクトします。また、セキュリティを確保するため、response_mode パラメータ form_post も渡します。
  3. Auth0 Authorization Server は、ユーザーをログインおよび認可の prompt にリダイレクトします。
  4. ユーザーは設定済みのログインオプションのいずれかで認証し、Auth0 がアプリに付与する permissions の一覧を示す同意ページが表示されることがあります。
  5. Auth0 Authorization Server は、ID トークンとともにユーザーをアプリにリダイレクトします。

​
実装方法

Express OpenID Connect SDK を使用して、Form Post を使用した Implicit Flow を安全に実装できます。
Auth0 Single-Page App SDK と Single-Page Quickstarts は新しい推奨事項に沿っており、PKCE を使用した Authorization Code フロー を使用します。
最後に、チュートリアルに従って API エンドポイントを使用し、Form Post を使用した Implicit Flow でログインを追加することもできます。

​
詳細はこちら