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 フローを使用してください。詳しくは、Authorization Code Flow with Proof Key for Code Exchange (PKCE) をお読みください。

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

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

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

​

前提条件

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

• アプリケーションの種類で Single-Page App を選択します。
• Allowed Callback URL に {https://yourApp/callback} を追加します。
• アプリケーションの グラントタイプ に 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 にする必要があります。このモードでは、レスポンスパラメータは HTML form の値としてエンコードされ、HTTP POST メソッドで送信される application/x-www-form-urlencoded 形式の本文に含まれます。
client_id	あなたのアプリケーションの Client ID です。この値は アプリケーションの設定 で確認できます。
redirect_uri	ユーザーが認可を付与した後に、Auth0 がブラウザーをリダイレクトする先の URL です。この URL は、Application Settings で有効なコールバック URL として指定する必要があります。 警告: OAuth 2.0 Specification に従い、Auth0 はハッシュ以降の内容をすべて削除し、フラグメントは考慮しません。
scope	認可をリクエストする スコープ を指定します。これにより、どのクレーム (またはユーザー属性) を返すかが決まります。複数指定する場合はスペースで区切る必要があります。profile や email など、ユーザーに関する任意の standard OpenID Connect (OIDC) スコープ、namespaced format に準拠した custom claims、または対象 API がサポートする任意の スコープ (たとえば read:contacts) をリクエストできます。
state	(推奨) アプリが最初の request に追加し、Auth0 がアプリケーションへのリダイレクト時に含める、不透明な任意の英数字文字列です。この値を使用してクロスサイトリクエストフォージェリ (CSRF) 攻撃を防ぐ方法については、Mitigate CSRF Attacks With State Parameters を参照してください。
nonce	(response_type に id_token token が含まれる場合は必須、それ以外は推奨) アプリが最初の request に追加し、Auth0 が ID トークン内に含める、暗号学的にランダムな文字列です。トークンのリプレイ攻撃を防ぐために使用されます。
connection	(任意) ユーザーが特定の 接続 を使ってサインインするよう指定します。たとえば、値として github を渡すと、ユーザーは GitHub アカウントでログインするために直接 GitHub に移動します。指定しない場合、ユーザーには構成済みのすべての 接続 が表示された Auth0 Lock 画面 が表示されます。構成済みの 接続 の一覧は、アプリケーションの Connections タブで確認できます。
organization	(任意) ユーザーの認証時に使用する organization の ID です。指定しない場合、アプリケーションで Display Organization Prompt を表示する設定になっていれば、ユーザーは認証時に organization名 を入力できます。
invitation	(任意) organization 招待の ticket ID です。Organization にメンバーを招待する 場合、ユーザーが招待を受け入れる際に、アプリケーションは invitation と organization のキーと値のペアを渡して、招待の受け入れを処理する必要があります。

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

​

レスポンス

問題なく進むと、HTTP 302 レスポンスが返されます。要求した資格情報はレスポンスボディにエンコードされています：

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

返される値は、response_type に何を指定したかによって異なる点に注意してください。

Response Type	Components
id_token	ID トークン
token	アクセストークン (expires_in と token_type の値を含む)
id_token token	ID トークン、アクセストークン (expires_in と token_type の値を含む)

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

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

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

​

ユースケース

​

基本的な認証リクエスト

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

これにより、ID トークンが返されます。この ID トークンはリダイレクト URL から取得できます。

​

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

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

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

これで、ID トークンに要求した name とプロフィール画像のクレームが含まれます。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 のようなソーシャルアイデンティティプロバイダーにユーザーを直接リダイレクトする方法を示します。この例を機能させるには、Auth0 Dashboard > 認証 > Social に移動して、適切な接続を設定する必要があります。接続名は 設定 タブで確認してください。

ユーザーを 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 使用時のリプレイ攻撃を防ぐ
• Single-Page Web Applications を登録する
• グラントタイプを更新する