認可コードフローを使用してログインを追加

認可コードフローを使用すると、ログインを通常のWebアプリケーションに追加することができます。フローの仕組みと使用すべき理由については、認可コードフローをお読みください。通常のWebアプリからAPIを呼び出すには、認可コードフローを使用してAPIを呼び出すをお読みください。認可コードフローの実装に、Auth0は以下のリソースを提供しています。

Regular Web App Quickstarts：フローを実装する最も簡単な方法。
Authentication API：独自のソリューションを構築したい場合は、このまま読み続けて、APIを直接呼び出す方法を学習してください。

ログインに成功すると、アプリケーションがユーザーの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の例

https://{yourDomain}/authorize?
    response_type=code&
    client_id={yourClientId}&
    redirect_uri={https://yourApp/callback}&
    scope={scope}&
    state={state}

パラメーター

パラメーター名	説明
`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スニペットは、以下のようになります：

<a href="https://{yourDomain}/authorize?
  response_type=code&
  client_id={yourClientId}&
  redirect_uri={https://yourApp/callback}&
  scope=openid%20profile&
  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_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"
}

トークンは、検証してから保存します。操作方法については、「IDトークンの検証」および「アクセストークンを検証する」を参照してください。

IDトークンには、デコードして抽出する必要があるユーザー情報が含まれています。アクセストークンは、Auth0認証APIの/userinfoエンドポイントまたは別のAPIを呼び出すために使用されます。独自のAPIを呼び出す場合にAPIが最初に行うのは、アクセストークンを検証することです。リフレッシュトークンは、アクセストークンまたはIDトークンの期限が切れたときに、新しいトークンの取得に使用されます。refresh_tokenは、offline_accessスコープを含め、DashboardでAPIの**［Allow Offline Access（オフラインアクセスの許可）］** を有効にした場合にのみ、応答内に表示されます。

リフレッシュトークンは、ユーザーが実質的に永久に認証された状態を維持できるようにするため、安全に保管しなければなりません。

ユースケース

基本的な認証要求

この例では、手順1でユーザーを認可する際に行う最も基本的な要求について説明します。Auth0のログイン画面を表示して、構成されている接続でユーザーがサインインできるようにします。

https://{yourDomain}/authorize?
    response_type=code&
    client_id={yourClientId}&
    redirect_uri={https://yourApp/callback}&
    scope=openid

トークンを要求する際に、IDトークンには最も基本的なクレームが含まれます。IDトークンをデコードする際には、以下のようになります。

{
  "iss": "https://auth0pnp.auth0.com/",
  "sub": "auth0|581...",
  "aud": "xvt9...",
  "exp": 1478112929,
  "iat": 1478076929
}

ユーザーの名前とプロファイルの写真を要求する

通常のユーザー認証に加えて、この例では名前や写真など、追加のユーザー詳細情報を要求する方法について説明します。ユーザーの名前や写真を要求するには、ユーザーを認可する際に、適切なスコープを追加する必要があります。

https://{yourDomain}/authorize?
    response_type=code&
    client_id={yourClientId}&
    redirect_uri={https://yourApp/callback}&
    scope=openid%20name%20picture&
    state={state}

トークンを要求する際に、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）に設定する必要があります：

https://{yourDomain}/authorize?
    response_type=code&
    client_id={yourClientId}&
    redirect_uri={https://yourApp/callback}&
    scope=openid%20name%20picture&
    state={state}&
    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
}

Auth0オンボーディング

基本を学ぶ

Auth0の構成

計画とデザイン

Auth0 AI

認可コードフローを使用してログインを追加

前提条件

ユーザーを認可する

認可URLの例

パラメーター

応答

トークンを要求する

トークンURLへのPOSTの例

パラメーター

応答

ユースケース

基本的な認証要求

ユーザーの名前とプロファイルの写真を要求する

GitHubでのユーザーログインを要求する

もっと詳しく

Auth0オンボーディング

基本を学ぶ

Auth0の構成

計画とデザイン

Auth0 AI

​前提条件

​ユーザーを認可する

​認可URLの例

​パラメーター

​応答

​トークンを要求する

​トークンURLへのPOSTの例

​パラメーター

​応答

​ユースケース

​基本的な認証要求

​ユーザーの名前とプロファイルの写真を要求する

​GitHubでのユーザーログインを要求する

​もっと詳しく

前提条件

ユーザーを認可する

認可URLの例

パラメーター

応答

トークンを要求する

トークンURLへのPOSTの例

パラメーター

応答

ユースケース

基本的な認証要求

ユーザーの名前とプロファイルの写真を要求する

GitHubでのユーザーログインを要求する

もっと詳しく