Form Post を使用した Implicit Flow でログインを追加する

Form Post を使用した Implicit Flow を使用して、シングルページアプリケーション（SPA）にログインを追加する方法を学びます。

Form Post を使用した Implicit Flow を使用すると、シングルページアプリケーション (SPA) にログインを追加できます。このフローの仕組みと、これを使用すべき理由については、Implicit Flow with Form Post を参照してください。

Form Post を使用した Implicit Flow は、ログイン専用のユースケースで使用してください。ユーザーのログイン時に アクセストークン をリクエストして API を呼び出す必要がある場合は、PKCE を使用する認可コードフローを使用してください。詳細については、Authorization Code Flow with Proof Key for Code Exchange (PKCE) を参照してください。

Form Post を使用した Implicit Flow を実装するには、次のリソースを使用できます。

• Express OpenID Connect SDK: フローを実装する最も簡単な方法で、煩雑な処理の大半を担います。Auth0 の JavaScript SDK を使用する場合は、ご利用のアーキテクチャに適した軽減策を実装していることを確認してください。詳細については、Auth0.js Reference を参照してください。
• Authentication API: 独自のソリューションを構築する場合は、このまま読み進めて API を直接呼び出す方法を確認してください。

ログインが成功すると、アプリケーションはユーザーの IDトークン にアクセスできるようになります。IDトークン には、基本的なユーザープロフィール情報が含まれます。

​

前提条件

アプリを Auth0 に登録します。詳細については、シングルページアプリケーションを登録するを参照してください。

• Application Type で Single-Page App を選択します。
• Allowed Callback URL に {https://yourApp/callback} を追加します。
• アプリケーションの Grant Types に Implicit が含まれていることを確認します。詳細については、グラントタイプを更新するを参照してください。

​

ユーザーを認可する

ユーザーに認可を求め、アプリにリダイレクトして戻します。フローを開始するには、ユーザーから認可を得る必要があります。このステップには、次のプロセスの 1 つ以上が含まれる場合があります。

• ユーザーを認証する;
• 認証を処理するために、ユーザーを IDプロバイダー にリダイレクトする;
• 有効な シングルサインオン (SSO) セッションがあるかどうかを確認する;
• 以前に同意が与えられていない場合は、要求された権限レベルについてユーザーの同意を得る。

ユーザーを認可するには、アプリはユーザーを認可 URL にリダイレクトする必要があります。

​

認可 URL の例

​

パラメーター

Parameter Name	Description
response_type	Auth0 が返す認証情報の種類 (code または token) を示します。Implicit Flow では、値として id_token、token、または id_token token を指定できます。具体的には、id_token は IDトークン を返し、token は アクセストークン を返します。
response_mode	レスポンスパラメーターの返却方法を指定します。セキュリティ上の理由から、値は form_post にする必要があります。このモードでは、レスポンスパラメーターは HTTP POST メソッドで送信される HTML フォームの値としてエンコードされ、application/x-www-form-urlencoded 形式でボディに格納されます。
client_id	アプリケーションの クライアントID です。この値は アプリケーションの設定 で確認できます。
redirect_uri	ユーザーが認可を付与した後に、Auth0 がブラウザーをリダイレクトする URL です。この URL は、Application Settings で有効な callback URL として指定する必要があります。 警告: OAuth 2.0 Specification に従い、Auth0 はハッシュ以降のすべてを削除し、フラグメントは いっさい考慮しません。
scope	認可をリクエストする スコープ を指定します。これにより、返されるクレーム (またはユーザー属性) が決まります。各値はスペースで区切る必要があります。profile や email などのユーザーに関する 標準 OpenID Connect (OIDC) scopes、namespaced format に準拠した カスタムクレーム、または対象 API がサポートする任意のスコープ (たとえば read:contacts) をリクエストできます。
state	(推奨) アプリが最初のリクエストに追加し、Auth0 がアプリケーションにリダイレクトする際に含める、不透明な任意の英数字文字列です。この値を使用して Cross-site Request Forgery (CSRF) 攻撃を防ぐ方法については、Mitigate CSRF Attacks With State Parameters を参照してください。
nonce	(response_type に id_token token が含まれる場合は必須、それ以外では推奨) アプリが最初のリクエストに追加し、Auth0 が IDトークン に含める、暗号学的にランダムな文字列です。トークンのリプレイ攻撃を防ぐために使用されます。
connection	(任意) ユーザーに特定の接続でサインインさせます。たとえば、値として github を渡すと、ユーザーは GitHub アカウントでログインするために直接 GitHub に送られます。指定しない場合、ユーザーには設定済みのすべての接続を含む Auth0 Lock 画面が表示されます。設定済みの接続の一覧は、アプリケーションの Connections タブで確認できます。
organization	(任意) ユーザーの認証時に使用する組織の ID です。指定しない場合、アプリケーションで Display Organization Prompt が設定されていれば、ユーザーは認証時に組織名を入力できます。
invitation	(任意) 組織への招待の ticket ID です。組織にメンバーを招待する 場合、ユーザーが招待を承諾したときに、アプリケーションは invitation と organization のキーと値のペアを転送して、招待の承諾を処理する必要があります。

例として、アプリにログインを追加する際の認可 URL 用 HTML スニペットは次のようになります。

​

レスポンス

問題なく処理されると、HTTP 302 レスポンスが返されます。要求した認証情報はレスポンス本文にエンコードされています。

HTTP/1.1 302 Found
Content-Type: application/x-www-form-urlencoded
id_token=eyJ...acA&
state=xyzABC123

返される値は、response_type として何をリクエストしたかによって異なることに注意してください。

レスポンスタイプ	コンポーネント
id_token	IDトークン
token	アクセストークン (expires_in と token_type の値を含む)
id_token token	IDトークン、アクセストークン (expires_in と token_type の値を含む)

Auth0 は、認可 URL の呼び出し時に含めた state 値も返します。

保存する前にトークンを検証してください。方法については、IDトークンを検証する および アクセストークンを検証する を参照してください。

IDトークンには、デコードして抽出する必要があるユーザー情報が含まれています。

​

利用例

​

基本認証リクエスト

この例は、手順 1 でユーザーを認証する際に送信できる最も基本的なリクエストを示しています。Auth0 のログイン画面が表示され、設定済みの任意の接続を使用してユーザーがサインインできます。

これにより IDトークン が返され、リダイレクト URL からその内容を解析できます。

​

ユーザーの名前とプロフィール画像を取得する

この例では、通常のユーザー認証に加えて、名前やプロフィール画像などの追加のユーザー情報を要求する方法を示します。

ユーザーの名前とプロフィール画像を要求するには、ユーザーの認可時に適切なスコープを追加する必要があります。

これで、IDトークンには要求した name クレーム と picture クレーム が含まれます。IDトークンをデコードすると、次のようになります。

{
  "name": "jerrie@...",
  "picture": "https://s.gravatar.com/avatar/6222081fd7dcea7dfb193788d138c457?s=480&r=pg&d=https%3A%2F%2Fcdn.auth0.com%2Favatars%2Fje.png",
  "iss": "https://auth0pnp.auth0.com/",
  "sub": "auth0|581...",
  "aud": "xvt...",
  "exp": 1478113129,
  "iat": 1478077129
}

​

GitHub でユーザーをログインさせる

この例では、通常のユーザー認証に加えて、GitHub などのソーシャル IDプロバイダーにユーザーを直接リダイレクトする方法を示します。この例を機能させるには、Auth0 Dashboard > Authentication > Social に移動し、適切な接続を設定する必要があります。接続名は Settings タブで確認してください。

ユーザーを GitHub のログイン画面に直接送るには、ユーザーの認可時に connection パラメーターを渡し、その値を接続名 (この場合は github) に設定する必要があります。

これで、IDトークンには GitHub から返されたユーザーの一意の ID を含む sub クレームが格納されます。IDトークンをデコードすると、次のようになります。

{
  "name": "Jerrie Pelser",
  "nickname": "jerriep",
  "picture": "https://avatars.githubusercontent.com/u/1006420?v=3",
  "iss": "https://auth0pnp.auth0.com/",
  "sub": "github|100...",
  "aud": "xvt...",
  "exp": 1478114742,
  "iat": 1478078742
}

​

詳しくはこちら

• OAuth 2.0 認可フレームワーク
• OpenID Connect プロトコル
• トークン
• Implicit Flow 使用時のリプレイ攻撃を軽減する
• シングルページ Web アプリケーションを登録する
• グラントタイプを更新する