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

​
仕組み

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

​
実装方法

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

​
詳しくはこちら