メインコンテンツへスキップ
このチュートリアルでは、認可コードフローを使用して独自のAPIを呼び出します。フローの仕組みやメリットについては、「認可コードフロー」を参照してください。通常のWebアプリにログインを追加する方法については、「認可コードフローを使用してログインを追加する」を参照してください。
Auth0を使用すると、以下を使用して簡単にアプリで フローを実装できます：
  • 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（オフラインアクセスの許可）］ を有効にします。

​
ステップ

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

​
認可URLの例

https://{yourDomain}/authorize?
    response_type=code&
    client_id={yourClientId}&
    redirect_uri={https://yourApp/callback}&
    scope={scope}&
    audience={apiAudience}&
    state={state}
パラメーター
ユーザーを認可するためにカスタムのAPIを呼び出すときは、
  • オーディエンスパラメーターを含めなければなりません。
  • ターゲットAPIでサポートされている追加のスコープを含めることができます。
パラメーター名説明
response_typeAuth0が返す認証情報の種類（codeまたはtoken）を示します。このフローでは、値はcodeである必要があります。
client_idアプリケーションのクライアントID。この値は［Application Settings（アプリケーション設定）］で確認できます。
redirect_uriユーザーによって認可が付与された後にAuth0がブラウザーをリダイレクトするURL。認可コードはcodeURLパラメーターで使用できます。このURLを［Application Settings（アプリケーション設定）］で有効なコールバックURLとして指定する必要があります。
警告：OAuth 2.0仕様に従って、Auth0はハッシュの後のすべてを削除し、フラグメントを考慮 しません 。
scope認可を要求するスコープを指定します。これにより、返されるクレーム（またはユーザー属性）が決まります。これらはスペースで区切る必要があります。ユーザーに関する標準OpenID Connect（OIDC）スコープ（profileやemailなど）、名前空間形式に準拠したカスタムクレーム、またはターゲットAPIでサポートされている任意のスコープ（例：read:contacts）をリクエストできます。を取得するには、offline_accessを含めます（［Application Settings（アプリケーション設定）］で__［Allow Offline Access（オフラインアクセスを許可する）］__フィールドが有効になっていることを確認してください）。
audienceWebアプリがアクセスするAPIの一意の識別子。このチュートリアルの前提条件の一部として作成したAPIのSettings（設定）タブの Identifier（識別子） 値を使用します。
state（推奨）Auth0がリダイレクトしてアプリケーションに戻る際に含まれ、アプリが初期要求に追加する不透明な任意の英数字の文字列。この値を使用してクロスサイトリクエストフォージェリ（CSRF）攻撃を防ぐ方法については、「状態パラメーターを使用してCSRF攻撃を軽減する」を参照してください。
organization（任意）ユーザーを認証するときに使用する組織のID。指定しない場合、アプリケーションがDisplay Organization Prompt（組織のプロンプトを表示） に設定されていると、ユーザーは認証時に組織名を入力できます。
invitation（任意）組織の招待のチケットID。Organizationにメンバーを招待する場合、ユーザーが招待を承諾したときに、アプリケーションはinvitationおよびorganizationキー/値ペアを転送することで、招待の受け入れを処理する必要があります。
たとえば、アプリにログインを追加する際の認可URLのHTMLスニペットは、以下のようになります：
<a href="https://{yourDomain}/authorize?
  response_type=code&
  client_id={yourClientId}&
  redirect_uri={https://yourApp/callback}&  
  scope=appointments%20contacts&
  audience=appointments:api&
  state=xyzABC123">
  Sign In
</a>

​
応答

すべてが成功すると、HTTP 302応答を受け取ります。認可コードはURLの末尾に含まれます：
HTTP/1.1 302 Found
Location: {https://yourApp/callback}?code={authorizationCode}&state=xyzABC123
取得した認可コードは、トークンと交換する必要があります。前の手順で抽出した認可コード（code）を使用して、トークンURLにPOSTする必要があります。

​
トークンURLへのPOSTの例

curl --request POST \
  --url 'https://{yourDomain}/oauth/token' \
  --header 'content-type: application/x-www-form-urlencoded' \
  --data grant_type=authorization_code \
  --data 'client_id={yourClientId}' \
  --data 'client_secret={yourClientSecret}' \
  --data 'code=yourAuthorizationCode}' \
  --data 'redirect_uri={https://yourApp/callback}'
パラメーター
パラメーター名説明
grant_typeauthorization_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応答を受信します。
{
  "access_token": "eyJz93a...k4laUWw",
  "refresh_token": "GEbRxBN...edjnXbL",
  "id_token": "eyJ0XAi...4faeEoQ",
  "token_type": "Bearer"
}
トークンは、検証してから保存します。操作方法については、「IDトークンの検証」および「アクセストークンを検証する」を参照してください。
IDトークンには、デコードして抽出する必要があるユーザー情報が含まれています。アクセストークンは、Auth0認証APIの/userinfoエンドポイントまたは別のAPIを呼び出すために使用されます。独自のAPIを呼び出す場合にAPIが最初に行うのは、アクセストークンを検証することです。リフレッシュトークンは、アクセストークンまたはIDトークンの期限が切れたときに、新しいトークンの取得に使用されます。refresh_tokenは、offline_accessスコープを含め、DashboardでAPIの**［Allow Offline Access（オフラインアクセスの許可）］** を有効にした場合にのみ、応答内に表示されます。
リフレッシュトークンは、ユーザーが実質的に永久に認証された状態を維持できるようにするため、安全に保管しなければなりません。
通常のWebアプリケーションからAPIを呼び出すには、アプリケーションは、取得したアクセストークンをベアラートークンとしてHTTP要求の認可ヘッダーで渡さなければなりません。
curl --request GET \
  --url https://myapi.com/api \
  --header 'authorization: Bearer {accessToken}' \
  --header 'content-type: application/json'
このチュートリアルに従って次の作業を完了している場合、あなたはすでにリフレッシュ トークンを受け取っています。
  • オフラインアクセスを許可するように、APIを構成する。
  • 認可エンドポイントを通じて認証要求を開始するときに、offline_accessスコープを含める。
リフレッシュトークンを使って新しいアクセストークンを取得することができます。通常、新しいアクセストークンが必要になるのは、以前のトークンの期限が切れたときや、新しいリソースに初めてアクセスする場合に限られます。APIを呼び出すたびにエンドポイントを呼び出して新しいアクセストークンを取得するのは、良くない習慣です。Auth0は、同じIPから同じトークンを使って実行できるエンドポイントへの要求数を、レート制限を通じて調整します。トークンを更新するには、grant_type=refresh_tokenを使用して、認証APIの/oauth/tokenエンドポイントに対してPOST要求を送信します。
トークンURLへのPOSTの例
curl --request POST \
  --url 'https://{yourDomain}/oauth/token' \
  --header 'content-type: application/x-www-form-urlencoded' \
  --data grant_type=refresh_token \
  --data 'client_id={yourClientId}' \
  --data 'refresh_token={yourRefreshToken}'
パラメーター
パラメーター名説明
grant_typeこれをrefresh_tokenに設定します。
client_idアプリケーションのクライアントID。この値はアプリケーション設定で確認できます。
refresh_token使用するリフレッシュトークン。
scope（任意）要求されたスコープの権限をスペースで区切ったリスト。送信されない場合は、元のスコープが使用されます。送信する場合は、スコープを減らして要求することができます。これはURLでエンコードされている必要があります。
応答
すべてが成功すると、新しいaccess_token、秒単位の有効期間（expires_in）、付与されたscope値、およびtoken_typeを含むペイロードとともにHTTP 200応答を受信します。最初のトークンのスコープにopenidが含まれている場合、応答には新しいid_tokenも含まれます。
{
  "access_token": "eyJ...MoQ",
  "expires_in": 86400,
  "scope": "openid offline_access",
  "id_token": "eyJ...0NE",
  "token_type": "Bearer"
}
トークンは、検証してから保存します。操作方法については、「IDトークンの検証」および「アクセストークンを検証する」を参照してください。

​
サンプルユースケース

​
トークンをカスタマイズする

Auth0 Actionsを使用すると、アクセストークンのスコープを変更したり、カスタムクレームをアクセストークンやIDトークンに追加したりできます。Actionsの詳細については、「Auth0 Actionsの仕組みを理解する」をお読みください。 これを行うには、以下のログイン後アクションを追加します。このアクションはユーザーの認証後に実行されます。 
exports.onExecutePostLogin = async (event, api) => {
  // Add custom claims to Access Token and ID Token
  api.accessToken.setCustomClaim('https://foo/bar', 'value');
  api.idToken.setCustomClaim('https://fiz/baz', 'some other value');

  // Modify the scope of the Access Token
  api.accessToken.addScope('foo');
  api.accessToken.addScope('bar');
};
Auth0は、プロファイル情報をOpenID Connect（OIDC）仕様で定義されている構造化クレーム形式で返します。つまり、IDトークンまたはアクセストークンに追加するカスタムクレームは、衝突を避けるためにガイドラインと制限に従わなければなりません。

​
もっと詳しく

⌘I