認可コードフローを使用すると、ログインを通常の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に送信する必要があります。
| パラメーター名 | 説明 |
|---|
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の末尾に含まれます：
取得した認可コードは、トークンと交換する必要があります。前の手順で抽出した認可コード（code）を使用して、トークン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の応答を受信します。
IDトークンには、デコードして抽出する必要があるユーザー情報が含まれています。
アクセストークンは、Auth0認証APIの/userinfoエンドポイントまたは別のAPIを呼び出すために使用されます。独自のAPIを呼び出す場合にAPIが最初に行うのは、アクセストークンを検証することです。
リフレッシュトークンは、アクセストークンまたはIDトークンの期限が切れたときに、新しいトークンの取得に使用されます。refresh_tokenは、offline_accessスコープを含め、DashboardでAPIの**［Allow Offline Access（オフラインアクセスの許可）］** を有効にした場合にのみ、応答内に表示されます。
リフレッシュトークンは、ユーザーが実質的に永久に認証された状態を維持できるようにするため、安全に保管しなければなりません。
connectionパラメーターを渡し、その値を接続名（この場合はgithub）に設定する必要があります：
これで、トークンを要求すると、IDトークンにはGitHubから返されたユーザーの一意のIDを含むsubクレームが含まれるようになります。IDトークンをデコードする際には、以下のようになります。
