- Regular Web App Quickstarts：フローを実装する最も簡単な方法。
- Authentication API：独自のソリューションを構築したい場合は、このまま読み続けて、APIを直接呼び出す方法を学習してください。
/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のHTMLスニペットは、以下のようになります：
応答
すべてが成功すると、HTTP 302応答を受け取ります。認可コードはURLの末尾に含まれます：
トークンを要求する
取得した認可コードは、トークンと交換する必要があります。前の手順で抽出した認可コード（code）を使用して、トークンURLにPOSTする必要があります。
トークンURLへのPOSTの例
パラメーター
応答
すべてが成功すると、access_token、refresh_token、id_token、およびtoken_typeの値を含むペイロードとともに、HTTP 200の応答を受信します。
refresh_tokenは、offline_accessスコープを含め、DashboardでAPIの**［Allow Offline Access（オフラインアクセスの許可）］** を有効にした場合にのみ、応答内に表示されます。
ユースケース
基本的な認証要求
この例では、手順1でユーザーを認可する際に行う最も基本的な要求について説明します。Auth0のログイン画面を表示して、構成されている接続でユーザーがサインインできるようにします。 トークンを要求する際に、IDトークンには最も基本的なクレームが含まれます。IDトークンをデコードする際には、以下のようになります。ユーザーの名前とプロファイルの写真を要求する
通常のユーザー認証に加えて、この例では名前や写真など、追加のユーザー詳細情報を要求する方法について説明します。 ユーザーの名前や写真を要求するには、ユーザーを認可する際に、適切なスコープを追加する必要があります。 トークンを要求する際に、IDトークンには要求された名前と写真のクレームが含まれます。IDトークンをデコードする際には、以下のようになります。GitHubでのユーザーログインを要求する
通常のユーザー認証に加えて、この例では、ユーザーをGitHubなどのソーシャルIDプロバイダーへ直接送る方法について説明します。まず、Auth0 Dashboard > Authentication ［Authentication（ 認証）］> Socialで適切な接続を構成し、［Settings（設定）］ タブから接続名を取得する必要があります。 ユーザーをGitHubログイン画面に直接送信するには、ステップ1でユーザーを認証するときに、connectionパラメーターを渡し、その値を接続名（この場合はgithub）に設定する必要があります：
これで、トークンを要求すると、IDトークンにはGitHubから返されたユーザーの一意のIDを含むsubクレームが含まれるようになります。IDトークンをデコードする際には、以下のようになります。