メインコンテンツへスキップ
フォームPOSTを使った暗黙フローでシングルページアプリケーション（SPA）へのログインを追加することができます。フローの仕組みやメリットについては、「フォームPOSTを使った暗黙フロー」をお読みください。 フォームPOSTを使った暗黙フローは、ログインのみのユースケースに使用します。ユーザーのログイン時にAPIを呼び出せるようにアクセストークンを要求する場合は、PKCEを使った認可コードフローを使用してください。詳細については、「Proof Key for Code Exchange（PKCE）を使った認可コードフロー」をお読みください。 フォームPOSTを使った暗黙フローを実装するには、以下のリソースを使用することができます。
  • Express OpenID Connect SDK：フローを実装する最も簡単な方法です。難しくて手間がかかる作業のほとんどが処理されます。Javascript SDKを使用する場合は、アーキテクチャに適した軽減措置を実施しているか確認してください。詳細については、「Auth0.js v9の参考情報」をお読みください。
  • Authentication API：独自のソリューションを構築したい場合は、このまま読み続けて、APIを直接呼び出す方法を学習してください。
ログインに成功すると、アプリケーションがユーザーのIDトークンにアクセスします。IDトークンには基本的なプロファイル情報が含まれます。

​
前提条件

アプリをAuth0に登録する必要があります。詳細については、「シングルページアプリケーションの登録」をお読みください。
  • ［Single-Page App（シングルページアプリ）］ を ［Application Type（アプリケーションタイプ）］ として選択します。
  • {https://yourApp/callback}の ［Allowed Callback URL（許可されているコールバックURL）］ を追加します。
  • アプリケーションの ［Grant Types（付与タイプ）］ に ［Implicit（暗黙）］ が含まれていることを確認します。詳細については、「付与タイプを更新する」をお読みください。

​
ユーザーを認可する

ユーザーの認可を要求しすると、アプリにリダイレクトされます。フローを開始するには、ユーザーの認可が必要です。この手順には、以下のようなプロセスが含まれます。
  • ユーザーを認証する
  • 認証を行うために、ユーザーをIDプロバイダーへリダイレクトする
  • 有効なシングルサインオン（）セッションを確認する
  • 以前に同意を得ていない場合は、要求された権限レベルについてユーザーの同意を得る
ユーザーを認可するには、アプリがユーザーに認可URLを送信する必要があります。

​
認可URLの例

https://{yourDomain}/authorize?
    response_type=YOUR_RESPONSE_TYPE&
    response_mode=form_post&
    client_id={yourClientId}&
    redirect_uri={https://yourApp/callback}&
    scope=SCOPE&
    state=STATE&
    nonce=NONCE

​
パラメーター

パラメーター名説明
response_typeAuth0が返す資格情報の種類を示します（コードまたはトークン）。暗黙フローに対して、値はid_token、token、id_token tokenになります。特に、id_tokenはIDトークンを返し、tokenはアクセストークンを返します。
response_mode応答パラメーターが返される方法を指定します。安全保護のため、値はform_postにする必要があります。このモードでは、応答パラメーターは、HTTP POSTメソッドを介して送信され、application/x-www-form-urlencodedフォーマットを使用して本文でエンコードされるHTMLフォーム値としてエンコードされます。
client_idアプリケーションのクライアントID。これは、アプリケーション設定で見つけることができます。
redirect_uri認可がユーザーにより付与された後にAuth0がブラウザをリダイレクトするURL。Application Settings（アプリケーション設定）で有効なCallback URLとしてこのURLを指定する必要があります。

警告： OAuth 2.0の仕様に従って、Auth0はハッシュの後、すべてを削除し、フラグメントを尊重しません。
scope返したいクレーム（またはユーザー属性）を決定する、認可を要求したいスコープを指定します。スペースで区切る必要があります。profileおよびemailなどのユーザーに関する標準OpenID Connect（OIDC）スコープ、名前空間形式に従ったカスタムクレーム、ターゲットAPIがサポートするスコープ（例：read:contacts）を要求できます。
state（推奨）Auth0がリダイレクトしてアプリケーションに戻る際に含まれ、アプリが初期要求に追加する不透明な任意の英数字の文字列。クロスサイトリクエストフォージェリ（CSRF）攻撃を防止するためにこの値を使用する方法については、状態パラメーターを使ってCSRF攻撃を軽減するをご覧ください。
nonce（id_token tokenを含むresponse_typeに必要、そうでない場合は推奨）トークンリプレイ攻撃を防ぐために使用される、アプリが初期要求に追加し、Auth0がIDトークンに含める暗号的にランダムな文字列。
connection（任意）特定の接続でユーザーにサインインを強制します。たとえば、githubの値を渡して、GitHubアカウントでログインするようにユーザーを直接GitHubに送信します。指定しなかった場合、ユーザーには、構成された接続すべてが表示されたAuth0 Lock画面が表示されます。アプリケーションのConnections（接続） タブで構成された接続のリストを確認できます。
organization（任意）ユーザーを認証する時に使用する組織のID。提供されない場合、アプリケーションはDisplay Organization Prompt（組織のプロンプトを表示） に設定され、ユーザーは、認証時に組織名を入力できます。
invitation（任意）組織の招待のチケットID。Organizationにメンバーを招待する場合、ユーザーが招待を受け入れたとき、アプリケーションは、invitationおよびorganizationのキー/値ペアを転送することで、招待の受け入れを処理する必要があります。
たとえば、アプリにログインを追加する際の認可URLのHTMLスニペットは、以下のようになります。 
<a href="https://{yourDomain}/authorize?
  response_type=id_token token&
  response_mode=form_post&
  client_id={yourClientId}&
  redirect_uri={https://yourApp/callback}&
  scope=read:tests&
  state=xyzABC123&
  nonce=eq...hPmz">
  Sign In
</a>

​
応答

すべてが成功すると、HTTP 302応答を受け取ります。要求された資格情報は本文にエンコードされます。 
HTTP/1.1 302 Found
Content-Type: application/x-www-form-urlencoded
id_token=eyJ...acA&
state=xyzABC123
返される値は、response_typeとして何を要求したかによって異なります。
応答タイプコンポーネント
id_tokenIDトークン
tokenアクセストークン（およびexpires_inとtoken_typeの値）
id_token tokenIDトークン、アクセストークン（およびexpires_inとtoken_typeの値）
Auth0は、認可URLへの呼び出しに含めた状態値も返します。
トークンは、検証してから保存します。操作方法については、「IDトークンの検証」および「アクセストークンを検証する」を参照してください。
IDトークンには、デコードして抽出する必要があるユーザー情報が含まれています。

​
ユースケース

​
基本的な認証要求

この例では、手順1でユーザーを認可する際に行う最も基本的な要求について説明します。Auth0のログイン画面を表示して、構成されている接続でユーザーがサインインできるようにします。 
https://{yourDomain}/authorize?
    response_type=id_token&
    response_mode=form_post&
    client_id={yourClientId}&
    redirect_uri={https://yourApp/callback}&
    nonce=NONCE
これによってIDトークンが返され、リダイレクトURLから解析することができます。

​
ユーザーの名前とプロファイルの写真を要求する

通常のユーザー認証に加えて、この例では名前や写真など、追加のユーザー詳細情報を要求する方法について説明します。 ユーザーの名前や写真を要求するには、ユーザーを認可する際に、適切なスコープを追加する必要があります。 
https://{yourDomain}/authorize?
    response_type=id_token token&
    response_mode=form_post&
    client_id={yourClientId}&
    redirect_uri={https://yourApp/callback}&
    scope=openid%20name%20picture&
    state=STATE&
    nonce=NONCE
これで、IDトークンには要求された名前と写真のクレームが含まれます。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）に設定する必要があります。 
https://{yourDomain}/authorize?
    response_type=id_token token&
    response_mode=form_post&
    client_id={yourClientId}&
    redirect_uri={https://yourApp/callback}&
    scope=openid%20name%20picture&
    state=STATE&
    nonce=NONCE&
    connection=github
これで、subクレームがGitHubから返されたユーザーの一意のIDとともにIDトークンに表示されます。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
}

​
もっと詳しく

⌘I