このチュートリアルでは、PKCEを使った認可コードフローを用いて、ネイティブやモバイル、シングルページのアプリから独自のAPIを呼び出します。フローの仕組みやメリットについては、「Proof Key for Code Exchange（PKCE）を使った認可コードフロー」をお読みください。ネイティブやモバイル、シングルページのアプリケーションにログインを追加する方法については、「PKCEを使った認可コードフローを使用してログインを追加する」をお読みください。
- Auth0 Mobile SDKとAuth0 Single-Page App SDK：フローを実装する最も簡単な方法です。難しくて手間がかかる作業のほとんどが処理されます。Mobile QuickstartsとSingle-Page App Quickstartsでこのプロセスについて説明しています。
- 認証API：独自のソリューションを構築したい場合は、このまま読み続けて、APIを直接呼び出す方法を学習してください。
前提条件
このチュートリアルを始める前に：-
Auth0にアプリケーションを登録します。
- アプリケーションタイプに応じて、［Native（ネイティブ）］ または ［Single-Page App（シングルページアプリ）］ の ［Application Type（アプリケーションタイプ）］ を選択します。
{yourCallbackUrl}の ［Allowed Callback URL（許可されているコールバックURL）］ を追加します。コールバックURLの形式は、使用しているアプリケーションタイプとプラットフォームによって異なります。アプリケーションタイプの形式とプラットフォームの詳細については、「Mobile/Native Quickstarts」と「Single-Page App Quickstarts」を参照してください。- アプリケーションの ［Grant Types（付与タイプ）］ に ［Authorization Code（認可コード）］ が必ず含まれていることを確認してください。詳細については、「付与タイプを更新する」をお読みください。
- アプリケーションでリフレッシュトークンを使用できるようにするには、アプリケーションの ［Grant Types（付与タイプ）］ に ［Refresh Token（リフレッシュトークン）］ が含まれていることを確認してください。詳細については、「付与タイプを更新する」をお読みください。リフレッシュトークンの詳細については、「リフレッシュトークン」をお読みください。
-
APIをAuth0に登録する
- APIがリフレッシュトークンを受信して、以前のトークンの有効期限が切れたときに新しいトークンを取得できるようにする場合は、［Allow Offline Access（オフラインアクセスの許可）］ を有効にします。
ステップ
- Code verifier（コード検証）を作成する：
トークンを要求するためにAuth0に送信される
code_verifierを生成します。 - コードチャレンジを作成する：
authorization_codeを要求するためにAuth0に送信されるcode_verifierからcode_challengeを生成します。 - ユーザーを認可する：
ユーザーの認可を要求すると、
authorization_codeでアプリにリダイレクトされます。 - トークンを要求する：
authorization_codeとcode_verifierをトークンと交換します。 - APIを呼び出す： 取得したアクセストークンを使ってAPIを呼び出します。
- リフレッシュトークン： 既存のトークンが期限切れになったら、リフレッシュトークンを使用して新しいトークンを要求します。
コードベリファイアを作成する
code_verifierを作成します。これは、トークンを要求するために最終的にAuth0に送信される、暗号的にランダムなBase64でエンコードされたキーです。
Javascriptのサンプル
Javaのサンプル
Androidのサンプル
Swift 5のサンプル
Objective-Cのサンプル
コードチャレンジを作成する
authorization_codeを要求するためにAuth0に送信されるcode_verifierからcode_challengeを生成します。
Javascriptのサンプル
Javaのサンプル
Swift 5のサンプル
Objective-Cのサンプル
ユーザーを認可する
code_verifierとcode_challengeを作成したら、ユーザーの認可を取得する必要があります。技術的には、これが認可フローの始まりとなります。この手順には以下のようなプロセスが含まれます：
* ユーザーを認証する。
* 認証を行うために、ユーザーをIDプロバイダーへリダイレクトする。
* アクティブなシングルサインオン（SSO）セッションを確認する。
* 以前に同意を得ていない場合は、要求された権限レベルについてユーザーの同意を得る。
ユーザーを認可するために、アプリは前のステップで生成したcode_challengeとcode_challengeの生成に使用したメソッドを含め、ユーザーを認可URLに送信する必要があります。
認可URLの例
パラメーター
ユーザーを認可するためにカスタムのAPIを呼び出すときは、- オーディエンスパラメーターを含めなければなりません。
- ターゲットAPIでサポートされている追加のスコープを含めることができます。
| パラメーター名 | 説明 |
|---|---|
response_type | Auth0が返す資格情報の種類（codeまたはtoken）を示します。このフローでは、値はcodeである必要があります。 |
code_challenge | code_verifierから生成されたチャレンジ。 |
code_challenge_method | チャレンジを生成するために使用されるメソッド（例：S256）。PKCE仕様では、S256とplainの2つのメソッドが定義されています。この例では前者が使用され、後者は推奨されていないため、Auth0でサポートされている唯一のメソッドです。 |
client_id | アプリケーションのクライアントID。この値は、［Application Settings（アプリケーション設定）］で確認できます。 |
redirect_uri | ユーザーによって認可が付与された後にAuth0がブラウザーをリダイレクトするURL。認可コードは、code URLパラメーターで利用できます。このURLを［Application Settings（アプリケーション設定）］で有効なコールバックURLとして指定する必要があります。警告： OAuth 2.0仕様に従って、Auth0はハッシュの後のすべてを削除し、フラグメントを受け付けません。 |
scope | 認可を要求するスコープ。これらはスペースで区切る必要があります。profileやemailなどのユーザーに関する標準OpenID Connect（OIDC）スコープ、名前空間形式に準拠したカスタムクレーム、またはターゲットAPIでサポートされているあらゆるスコープ（例：read:contacts）を要求できます。を取得するには、offline_accessを含めます（［Application Settings（アプリケーション設定）］で__［Allow Offline Access（オフラインアクセスを許可する）］__フィールドが有効になっていることを確認してください）。 |
audience | WebアプリがアクセスするAPIの一意の識別子。このチュートリアルの前提条件の一部として作成したAPIの［Settings（設定）］タブのIdentifier（識別子） 値を使用します。 |
state | （推奨）Auth0がリダイレクトしてアプリケーションに戻る際に含まれ、アプリが初期要求に追加する不透明な任意の英数字の文字列。この値を使用してクロスサイトリクエストフォージェリ（CSRF）攻撃を防ぐ方法については、状態パラメーターを使用してCSRF攻撃を軽減するを参照してください。 |
organization | （任意）ユーザーを認証するときに使用する組織のID。指定しない場合、アプリケーションがDisplay Organization Prompt（組織のプロンプトを表示） に設定されていると、ユーザーは認証時に組織名を入力できます。 |
invitation | （任意）組織の招待のチケットID。Organizationにメンバーを招待する場合、ユーザーが招待を承諾したときに、アプリケーションはinvitationおよびorganizationキー/値ペアを転送して招待の受け入れを処理する必要があります。 |
応答
すべてが成功すると、HTTP 302応答を受け取ります。認可コードはURLの末尾に含まれます：
トークンを要求する
取得した認可コードは、トークンと交換する必要があります。前の手順で抽出した認可コード（code）を使用して、code_verifierとともに送信するトークンURLにPOSTする必要があります。
トークンURLへのPOSTの例
パラメーター
| パラメーター | 説明 |
|---|---|
grant_type | これをauthorization_codeに設定します。 |
code_verifier | 暗号的にランダムなキーです。このチュートリアルの最初の手順で生成しました。 |
code | このチュートリアルの前の手順で取得したauthorization_codeです。 |
client_id | アプリケーションのクライアントIDです。この値は［Application Settings（アプリケーションの設定）］にあります。 |
redirect_uri | アプリケーションの設定で指定されている有効なコールバックURLです。このチュートリアルの前の手順で認可URLに渡されたredirect_uriと完全に一致しなければなりません。これは、URLエンコードする必要があります。 |
応答
すべてが成功すると、access_token、refresh_token、id_token、およびtoken_typeの値を含むペイロードとともに、HTTP 200の応答を受信します。
トークンは、検証してから保存します。操作方法については、「IDトークンの検証」および「アクセストークンを検証する」を参照してください。
refresh_tokenは、offline_accessスコープを含め、DashboardでAPIの**［Allow Offline Access（オフラインアクセスの許可）］** を有効にした場合にのみ、応答内に表示されます。
リフレッシュトークンは、ユーザーが実質的に永久に認証された状態を維持できるようにするため、安全に保管しなければなりません。
APIを呼び出す
ネイティブ/モバイルアプリケーションからAPIを呼び出すには、アプリケーションは、取得したアクセストークンをBearerトークンとしてHTTP要求の認証ヘッダーで渡さなければなりません。リフレッシュトークン
このチュートリアルに従って次の作業を完了している場合、あなたはすでにリフレッシュ トークンを受け取っています。- オフラインアクセスを許可するように、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も含まれます。
トークンは、検証してから保存します。操作方法については、「IDトークンの検証」および「アクセストークンを検証する」を参照してください。
サンプルユースケース
トークンをカスタマイズする
ルールを使用して、アクセストークンで返されたスコープを変更し、クレームをアクセスとIDトークンに追加することができます。（ルールの詳細については、「Auth0ルール」をお読みください。）これを行うには、ユーザーの認証後に実行される次のルールを追加します。Auth0は、プロファイル情報をOpenID Connect（OIDC）仕様で定義されている構造化クレーム形式で返します。つまり、IDトークンまたはアクセストークンに追加するカスタムクレームは、衝突を避けるためにガイドラインと制限に従わなければなりません。