フォームPOSTを使った暗黙フロー
「暗黙」という言葉を誤解しないよう注意してください。OAuthでは、現在、SPAでのアクセストークンの取得に暗黙の付与を使用することを奨励していませんが、フォームPOSTを使った暗黙フローで対処するシナリオは、これとはまったく異なり、SPAで使用する場合のようなセキュリティ上の問題が生じません。具体的に言うと、フォームPOSTを使った暗黙フローは、SPAとは対照的に従来型のWebアプリに適用されます。また、取得するのはアクセストークンではなく、使用目的のまったく異なるIDトークンです。このフローは、POSTを使用し、（SPAのように）トークン情報がブラウザー履歴攻撃やヘッダーのリダイレクトなどにさらされる可能性のあるURLフラグメントにトークンを配置することはありません。
従来型のWebアプリにWebサインインを実装するために、OpenID Connect（OIDC）を多くの異なるフローで使用することができます。典型的なフローでは、アプリのバックエンドで認可コードフローを実行することにより、IDトークンが取得されます。この方法は効果的で安定性も高い反面、アプリがシークレットを取得して管理する必要があります。目的がサインインを実装することだけで、APIの実行にアクセストークンを取得する必要がない場合には、この負荷を避けることができます。
フォームPOSTを使った暗黙フローはOIDCを使用して、SAMLやWS-Federationに類似したWebサインインを実装します。Webアプリは、フロントチャネルを介してトークンを要求し、取得します。シークレットや追加でバックエンドを呼び出す必要はありません。この方法では、アプリケーションでシークレットの取得や管理、使用、保護を必要としません。
仕組み
このフローは、ログインのみのユースケースに使用します。ユーザーのログイン時にAPIを呼び出せるようにアクセストークンを要求する場合は、PKCEを使った認可コードフローまたはハイブリッドフローを使用してください。
ユーザーはアプリで ［Login（ログイン）］ をクリックします。
Auth0の SDKは、ユーザーをAuth0認可サーバー (
/authorizeendpoint)にリダイレクトし、要求された資格情報の種類を示すid_tokenのresponse_typeパラメータを渡します。また、セキュリティを確保するためにform_postのresponse_modeパラメータも渡します。Auth0の認可サーバーがユーザーをログインにリダイレクトして、認可を促します。
ユーザーは構成されたログインオプションの1つを使用して認証を行い、Auth0がアプリに与える許可をリストした同意ページが表示されることもあります。
Auth0認可サーバーは、IDトークンを添えて、ユーザーをリダイレクトでアプリへ戻します。
実装方法
OktaのExpress OpenID Connect SDKを使用して、フォームポストを使用した暗黙フローを安全に実装することができます。
Auth0 Single-Page App SDKとSingle-Page Quickstartsは、新しい推奨に従い、PKCEを使った認可コードフローを使用します。
最後に、チュートリアルに従って、APIエンドポイントを使用して、フォームポストを使用した暗黙フローでのログインを追加することができます。