このチュートリアルでは、認可コードフローを使用して独自のAPIを呼び出します。フローの仕組みやメリットについては、「認可コードフロー」を参照してください。通常のWebアプリにログインを追加する方法については、「認可コードフローを使用してログインを追加する」を参照してください。
- Regular Web App Quickstarts:フローを実装する最も簡単な方法。
- Authentication API:独自のソリューションを構築したい場合は、このまま読み続けて、APIを直接呼び出す方法を学習してください。
前提条件
-
Auth0にアプリケーションを登録します。
- [Regular Web Apps(通常のWebアプリ)] の [Application Type(アプリケーションタイプ)] を選択します。
{https://yourApp/callback}の [Allowed Callback URL(許可されているコールバックURL)] を追加します。- アプリケーションの [Grant Types(付与タイプ)] に [Authorization Code(認可コード)] が必ず含まれていることを確認してください。詳細については、「付与タイプを更新する」をお読みください。
- アプリケーションでリフレッシュトークンを使用できるようにする場合は、アプリケーションの [Grant Types(付与タイプ)] に [Refresh Token(リフレッシュトークン)] が含まれていることを確認してください。詳細については、「付与タイプを更新する」をお読みください。
-
APIをAuth0に登録する
- APIがリフレッシュトークンを受信して、以前のトークンの有効期限が切れたときに新しいトークンを取得できるようにする場合は、[Allow Offline Access(オフラインアクセスの許可)] を有効にします。
ステップ
1 ユーザーを認可する
1 ユーザーを認可する
この手順には、以下のようなプロセスが含まれます。
- ユーザーを認証する
- 認証を行うために、ユーザーをIDプロバイダーへリダイレクトする
- 有効なシングルサインオン(SSO)セッションを確認する
- 以前に同意を得ていない場合は、要求された権限レベルについてユーザーの同意を得る
認可URLの例
パラメーター
ユーザーを認可するためにカスタムのAPIを呼び出すときは、- オーディエンスパラメーターを含めなければなりません。
- ターゲットAPIでサポートされている追加のスコープを含めることができます。
たとえば、アプリにログインを追加する際の認可URLのHTMLスニペットは、以下のようになります:
応答
すべてが成功すると、HTTP 302応答を受け取ります。認可コードはURLの末尾に含まれます:2 トークンを要求する
2 トークンを要求する
取得した認可コードは、トークンと交換する必要があります。前の手順で抽出した認可コード(
IDトークンには、デコードして抽出する必要があるユーザー情報が含まれています。アクセストークンは、Auth0認証APIの/userinfoエンドポイントまたは別のAPIを呼び出すために使用されます。独自のAPIを呼び出す場合にAPIが最初に行うのは、アクセストークンを検証することです。リフレッシュトークンは、アクセストークンまたはIDトークンの期限が切れたときに、新しいトークンの取得に使用されます。
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、fresh_token、id_token、およびtoken_typeの値を含むペイロードとともにHTTP 200応答を受信します。refresh_tokenは、offline_accessスコープを含め、DashboardでAPIの**[Allow Offline Access(オフラインアクセスの許可)]** を有効にした場合にのみ、応答内に表示されます。3 APIを呼び出す
3 APIを呼び出す
通常のWebアプリケーションからAPIを呼び出すには、アプリケーションは、取得したアクセストークンをベアラートークンとしてHTTP要求の認可ヘッダーで渡さなければなりません。
4 リフレッシュトークンを交換する
4 リフレッシュトークンを交換する
このチュートリアルに従って次の作業を完了している場合、あなたはすでにリフレッシュ トークンを受け取っています。
- オフラインアクセスを許可するように、APIを構成する。
- 認可エンドポイントを通じて認証要求を開始するときに、
offline_accessスコープを含める。
grant_type=refresh_tokenを使用して、認証APIの/oauth/tokenエンドポイントに対してPOST要求を送信します。トークンURLへのPOSTの例
パラメーター
| パラメーター名 | 説明 |
|---|---|
grant_type | これをrefresh_tokenに設定します。 |
client_id | アプリケーションのクライアントID。この値はアプリケーション設定で確認できます。 |
refresh_token | 使用するリフレッシュトークン。 |
scope | (任意)要求されたスコープの権限をスペースで区切ったリスト。送信されない場合は、元のスコープが使用されます。送信する場合は、スコープを減らして要求することができます。これはURLでエンコードされている必要があります。 |
応答
すべてが成功すると、新しいaccess_token、秒単位の有効期間(expires_in)、付与されたscope値、およびtoken_typeを含むペイロードとともにHTTP 200応答を受信します。最初のトークンのスコープにopenidが含まれている場合、応答には新しいid_tokenも含まれます。