認可コードフローを使用すると、ログインを通常のWebアプリケーションに追加することができます。フローの仕組みと使用すべき理由については、認可コードフローをお読みください。通常のWebアプリからAPIを呼び出すには、認可コードフローを使用してAPIを呼び出すをお読みください。
認可コードフローの実装に、Auth0は以下のリソースを提供しています。
ログインに成功すると、アプリケーションがユーザーのIDトークンとアクセストークンにアクセスします。IDトークンには基本的なユーザープロファイル情報が含まれており、アクセストークンはAuth0の/userinfoエンドポイントまたは独自の保護されたAPIを呼び出すために使用できます。IDトークンの詳細については、「IDトークン」をお読みください。アクセストークンの詳細については、「アクセストークン」をお読みください。
ユーザーの認可を要求しauthorization_codeを使用してアプリにリダイレクトします。そして、トークンのコードを交換します。
前提条件
アプリをAuth0に登録する必要があります。詳しくは、通常のWebアプリケーションを登録するをお読みください。
- ［Application Type（アプリケーションタイプ）］として［Regular Web App（通常のWebアプリ）］ を選択します。
{https://yourApp/callback}の ［Allowed Callback URL（許可されているコールバックURL）］ を追加します。- アプリケーションの ［Grant Types（付与タイプ）］ に ［Authorization Code（認可コード）］ が必ず含まれていることを確認してください。詳細については、「付与タイプを更新する」をお読みください。
ユーザーを認可する
フローを開始するには、ユーザーの認可が必要です。この手順には、以下のようなプロセスが含まれます。
- ユーザーを認証する
- 認証を行うために、ユーザーをIDプロバイダーへリダイレクトする
- 以前に同意を得ていない場合は、要求された権限レベルについてユーザーの同意を得る
ユーザーを認可するには、アプリがユーザーを認可URLに送信する必要があります。
認可URLの例
パラメーター
| パラメーター名 | 説明 |
|---|
response_type | Auth0が返す資格情報の種類を示します（codeまたはtoken）。このフローでは、値はcodeでなければなりません。 |
client_id | アプリケーションのクライアントID。この値は、アプリケーション設定で見つけることができます。 |
redirect_uri | 認可がユーザーにより付与された後にAuth0がブラウザーをリダイレクトするURL。認可コードは、code URLパラメーターで利用できます。アプリケーション設定で有効なコールバックURLとしてこのURLを指定する必要があります。
警告： OAuth 2.0の仕様に従って、Auth0はハッシュの後、すべてを削除し、フラグメントを受け付けません。 |
scope | 返したいクレーム（またはユーザー属性）を決定する、認可を要求したいスコープを指定します。スペースで区切る必要があります。応答でIDトークンを取るには、少なくともopenidのスコープを指定する必要があります。ユーザーのフルプロファイルを返したい場合は、openid profileを要求できます。emailなどのユーザーに関する標準OpenID Connect（OIDC)スコープまたは名前空間形式に従ったカスタムクレームを要求できます。offline_accessを含めてを取得できます（Allow Offline Access（オフラインアクセスの許可）フィールドがアプリケーション設定で有効になっていることを確認してください）。 |
state | （推奨）Auth0がリダイレクトしてアプリケーションに戻る際に含まれ、アプリが初期要求に追加する不透明な任意の英数字の文字列。クロスサイトリクエストフォージェリ（CSRF）攻撃を防止するためにこの値を使用する方法については、状態パラメーターを使ってCSRF攻撃を軽減するをご覧ください。 |
connection | （任意）特定の接続でユーザーにサインインを強制します。たとえば、githubの値を渡して、GitHubアカウントでログインするようにユーザーを直接GitHubに送信します。指定しなかった場合、ユーザーには、構成された接続すべてが表示されたAuth0 Lock画面が表示されます。アプリケーションのConnections（接続） タブで構成された接続のリストを確認できます。 |
organization | （任意）ユーザーを認証する時に使用する組織のID。提供されない場合、アプリケーションはDisplay Organization Prompt（組織のプロンプトを表示） に設定され、ユーザーは、認証時に組織名を入力できます。 |
invitation | （任意）組織の招待のチケットID。[Organizationにメンバーを招待する]場合(/organizations/invite-members)、ユーザーが招待を受け入れたとき、アプリケーションは、invitationおよびorganizationのキー/値ペアを転送することで、招待の受け入れを処理する必要があります。 |
login_hint | （任意）Auth0にリダイレクトされるときに、ログインまたはサインアップページの識別子フィールドに入力します。ユニバーサルログインエクスペリエンスがサポートしています。 |
たとえば、アプリにログインを追加する際の認可URLのHTMLスニペットは、以下のようになります：
すべてが成功すると、HTTP 302応答を受け取ります。認可コードはURLの末尾に含まれます：
HTTP/1.1 302 Found
Location: {https://yourApp/callback}?code={authorizationCode}&state=xyzABC123
トークンを要求する
取得した認可コードは、トークンと交換する必要があります。前の手順で抽出した認可コード（code）を使用して、トークンURLにPOSTする必要があります。
トークンURLへのPOSTの例
パラメーター
| パラメーター名 | 説明 |
|---|
grant_type | authorization_codeに設定します。 |
code | このチュートリアルの前の手順で取得したauthorization_codeです。 |
client_id | アプリケーションのクライアントIDです。この値は［Application Settings（アプリケーションの設定）］で見つけることができます。 |
client_secret | アプリケーションのクライアントシークレットです。この値は［Application Settings（アプリケーションの設定）］で見つけることができます。アプリケーションの認証方法については、「アプリケーションの資格情報」をお読みください。 |
redirect_uri | アプリケーションの設定で指定されている有効なコールバックURLです。このチュートリアルの前の手順で認可URLに渡されたredirect_uriと完全に一致しなければなりません。これは、URLエンコードする必要があります。 |
すべてが成功すると、access_token、refresh_token、id_token、およびtoken_typeの値を含むペイロードとともに、HTTP 200の応答を受信します。
{
"access_token": "eyJz93a...k4laUWw",
"refresh_token": "GEbRxBN...edjnXbL",
"id_token": "eyJ0XAi...4faeEoQ",
"token_type": "Bearer"
}
refresh_tokenは、offline_accessスコープを含め、DashboardでAPIの**［Allow Offline Access（オフラインアクセスの許可）］** を有効にした場合にのみ、応答内に表示されます。
リフレッシュトークンは、ユーザーが実質的に永久に認証された状態を維持できるようにするため、安全に保管しなければなりません。
ユースケース
基本的な認証要求
この例では、手順1でユーザーを認可する際に行う最も基本的な要求について説明します。Auth0のログイン画面を表示して、構成されている接続でユーザーがサインインできるようにします。
トークンを要求する際に、IDトークンには最も基本的なクレームが含まれます。IDトークンをデコードする際には、以下のようになります。
{
"iss": "https://auth0pnp.auth0.com/",
"sub": "auth0|581...",
"aud": "xvt9...",
"exp": 1478112929,
"iat": 1478076929
}
ユーザーの名前とプロファイルの写真を要求する
通常のユーザー認証に加えて、この例では名前や写真など、追加のユーザー詳細情報を要求する方法について説明します。
ユーザーの名前や写真を要求するには、ユーザーを認可する際に、適切なスコープを追加する必要があります。
トークンを要求する際に、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 ［Authentication（ 認証）］> Socialで適切な接続を構成し、［Settings（設定）］ タブから接続名を取得する必要があります。
ユーザーをGitHubログイン画面に直接送信するには、ステップ1でユーザーを認証するときに、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
}
もっと詳しく
