PKCEを使った認可コードフローで独自のAPIを呼び出し

このチュートリアルでは、PKCEを使った認可コードフローを用いて、ネイティブやモバイル、シングルページのアプリから独自のAPIを呼び出します。フローの仕組みやメリットについては、「Proof Key for Code Exchange（PKCE）を使った認可コードフロー」をお読みください。ネイティブやモバイル、シングルページのアプリケーションにログインを追加する方法については、「PKCEを使った認可コードフローを使用してログインを追加する」をお読みください。

Auth0を使用すると、以下を使用して簡単にアプリでProof Key for Code Exchange（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のサンプル

// Dependency: Node.js crypto module
// https://nodejs.org/api/crypto.html#crypto_crypto
function base64URLEncode(str) {
    return str.toString('base64')
        .replace(/\+/g, '-')
        .replace(/\//g, '_')
        .replace(/=/g, '');
}
var verifier = base64URLEncode(crypto.randomBytes(32));

Javaのサンプル

// Dependency: Apache Commons Codec
// https://commons.apache.org/proper/commons-codec/
// Import the Base64 class.
// import org.apache.commons.codec.binary.Base64;
SecureRandom sr = new SecureRandom();
byte[] code = new byte[32];
sr.nextBytes(code);
String verifier = Base64.getUrlEncoder().withoutPadding().encodeToString(code);

Androidのサンプル

// See https://developer.android.com/reference/android/util/Base64
// Import the Base64 class
// import android.util.Base64;
SecureRandom sr = new SecureRandom();
byte[] code = new byte[32];
sr.nextBytes(code);
String verifier = Base64.encodeToString(code, Base64.URL_SAFE | Base64.NO_WRAP | Base64.NO_PADDING);

Swift 5のサンプル

var buffer = [UInt8](repeating: 0, count: 32)
_ = SecRandomCopyBytes(kSecRandomDefault, buffer.count, &buffer)
let verifier = Data(buffer).base64EncodedString()
    .replacingOccurrences(of: "+", with: "-")
    .replacingOccurrences(of: "/", with: "_")
    .replacingOccurrences(of: "=", with: "")

Objective-Cのサンプル

NSMutableData *data = [NSMutableData dataWithLength:32];
int result __attribute__((unused)) = SecRandomCopyBytes(kSecRandomDefault, 32, data.mutableBytes);
NSString *verifier = [[[[data base64EncodedStringWithOptions:0]
                        stringByReplacingOccurrencesOfString:@"+" withString:@"-"]
                        stringByReplacingOccurrencesOfString:@"/" withString:@"_"]
                        stringByTrimmingCharactersInSet:[NSCharacterSet characterSetWithCharactersInString:@"="]];

コードチャレンジを作成する

authorization_codeを要求するためにAuth0に送信されるcode_verifierからcode_challengeを生成します。

Javascriptのサンプル

// Dependency: Node.js crypto module
// https://nodejs.org/api/crypto.html#crypto_crypto
function sha256(buffer) {
    return crypto.createHash('sha256').update(buffer).digest();
}
var challenge = base64URLEncode(sha256(verifier));

Javaのサンプル

// Dependency: Apache Commons Codec
// https://commons.apache.org/proper/commons-codec/
// Import the Base64 class.
// import org.apache.commons.codec.binary.Base64;
byte[] bytes = verifier.getBytes("US-ASCII");
MessageDigest md = MessageDigest.getInstance("SHA-256");
md.update(bytes, 0, bytes.length);
byte[] digest = md.digest();
String challenge = Base64.encodeBase64URLSafeString(digest);

Swift 5のサンプル

import CommonCrypto

// ...

guard let data = verifier.data(using: .utf8) else { return nil }
var buffer = [UInt8](repeating: 0, count: Int(CC_SHA256_DIGEST_LENGTH))
_ = data.withUnsafeBytes {
    CC_SHA256($0.baseAddress, CC_LONG(data.count), &buffer)
}
let hash = Data(buffer)
let challenge = hash.base64EncodedString()
    .replacingOccurrences(of: "+", with: "-")
    .replacingOccurrences(of: "/", with: "_")
    .replacingOccurrences(of: "=", with: "")

Objective-Cのサンプル

// Dependency: Apple Common Crypto library
// http://opensource.apple.com//source/CommonCrypto
u_int8_t buffer[CC_SHA256_DIGEST_LENGTH * sizeof(u_int8_t)];
memset(buffer, 0x0, CC_SHA256_DIGEST_LENGTH);
NSData *data = [verifier dataUsingEncoding:NSUTF8StringEncoding];
CC_SHA256([data bytes], (CC_LONG)[data length], buffer);
NSData *hash = [NSData dataWithBytes:buffer length:CC_SHA256_DIGEST_LENGTH];
NSString *challenge = [[[[hash base64EncodedStringWithOptions:0]
                         stringByReplacingOccurrencesOfString:@"+" withString:@"-"]
                         stringByReplacingOccurrencesOfString:@"/" withString:@"_"]
                         stringByTrimmingCharactersInSet:[NSCharacterSet characterSetWithCharactersInString:@"="]];

ユーザーを認可する

code_verifierとcode_challengeを作成したら、ユーザーの認可を取得する必要があります。技術的には、これが認可フローの始まりとなります。この手順には以下のようなプロセスが含まれます： * ユーザーを認証する。 * 認証を行うために、ユーザーをIDプロバイダーへリダイレクトする。 * アクティブなシングルサインオン（SSO）セッションを確認する。 * 以前に同意を得ていない場合は、要求された権限レベルについてユーザーの同意を得る。ユーザーを認可するために、アプリは前のステップで生成したcode_challengeとcode_challengeの生成に使用したメソッドを含め、ユーザーを認可URLに送信する必要があります。

認可URLの例

https://{yourDomain}/authorize?
    response_type=code&
    code_challenge={codeChallenge}&
    code_challenge_method=S256&
    client_id={yourClientId}&
    redirect_uri={yourCallbackUrl}&
    scope=SCOPE&
    audience={apiAudience}&
    state={state}

パラメーター

ユーザーを認可するためにカスタムの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`キー/値ペアを転送して招待の受け入れを処理する必要があります。

たとえば、APIを呼び出す際の認可URLのHTMLスニペットは、以下のようになります。

<a href="https://{yourDomain}/authorize?
  response_type=code&
  client_id={yourClientId}&
  code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM&
  code_challenge_method=S256&
  redirect_uri={yourCallbackUrl}&
  scope=appointments%20contacts&
  audience=appointments:api&
  state=xyzABC123">
  Sign In
</a>

応答

すべてが成功すると、HTTP 302応答を受け取ります。認可コードはURLの末尾に含まれます：

HTTP/1.1 302 Found
Location: {yourCallbackUrl}?code={authorizationCode}&state=xyzABC123

トークンを要求する

取得した認可コードは、トークンと交換する必要があります。前の手順で抽出した認可コード（code）を使用して、code_verifierとともに送信するトークン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 'code_verifier={yourGeneratedCodeVerifier}' \
  --data 'code={yourAuthorizationCode}' \
  --data 'redirect_uri={https://yourApp/callback}'

パラメーター

パラメーター	説明
`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の応答を受信します。

{
  "access_token":"eyJz93a...k4laUWw",
  "refresh_token":"GEbRxBN...edjnXbL",
  "id_token":"eyJ0XAi...4faeEoQ",
  "token_type":"Bearer",
  "expires_in":86400
}

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

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

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

APIを呼び出す

ネイティブ/モバイルアプリケーションからAPIを呼び出すには、アプリケーションは、取得したアクセストークンをBearerトークンとして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トークンの検証」および「アクセストークンを検証する」を参照してください。

サンプルユースケース

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

ルールを使用して、アクセストークンで返されたスコープを変更し、クレームをアクセスとIDトークンに追加することができます。（ルールの詳細については、「Auth0ルール」をお読みください。）これを行うには、ユーザーの認証後に実行される次のルールを追加します。

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トークンまたはアクセストークンに追加するカスタムクレームは、衝突を避けるためにガイドラインと制限に従わなければなりません。

サンプルアプリケーションを表示する：モバイルアプリ + API

サンプル実装の場合、モバイル + APIアーキテクチャのシナリオを参照してください。この一連のチュートリアルには、付録にGitHubで提供されているコードのサンプルがあります。

Auth0オンボーディング

基本を学ぶ

Auth0の構成

計画とデザイン

Auth0 AI

PKCEを使った認可コードフローで独自のAPIを呼び出し

前提条件

ステップ

コードベリファイアを作成する

Javascriptのサンプル

Javaのサンプル

Androidのサンプル

Swift 5のサンプル

Objective-Cのサンプル

コードチャレンジを作成する

Javascriptのサンプル

Javaのサンプル

Swift 5のサンプル

Objective-Cのサンプル

ユーザーを認可する

認可URLの例

パラメーター

応答

トークンを要求する

トークンURLへのPOSTの例

パラメーター

応答

APIを呼び出す

リフレッシュトークン

トークンURLへのPOSTの例

パラメーター

応答

サンプルユースケース

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

サンプルアプリケーションを表示する：モバイルアプリ + API

もっと詳しく

Auth0オンボーディング

基本を学ぶ

Auth0の構成

計画とデザイン

Auth0 AI

​前提条件

​ステップ

​コードベリファイアを作成する

​Javascriptのサンプル

​Javaのサンプル

​Androidのサンプル

​Swift 5のサンプル

​Objective-Cのサンプル

​コードチャレンジを作成する

​Javascriptのサンプル

​Javaのサンプル

​Swift 5のサンプル

​Objective-Cのサンプル

​ユーザーを認可する

​認可URLの例

パラメーター

​応答

​トークンを要求する

​トークンURLへのPOSTの例

パラメーター

​応答

​APIを呼び出す

​リフレッシュトークン

​トークンURLへのPOSTの例

パラメーター

​応答

​サンプルユースケース

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

​サンプルアプリケーションを表示する：モバイルアプリ + API

​もっと詳しく

前提条件

ステップ

コードベリファイアを作成する

Javascriptのサンプル

Javaのサンプル

Androidのサンプル

Swift 5のサンプル

Objective-Cのサンプル

コードチャレンジを作成する

Javascriptのサンプル

Javaのサンプル

Swift 5のサンプル

Objective-Cのサンプル

ユーザーを認可する

認可URLの例

応答

トークンを要求する

トークンURLへのPOSTの例

応答

APIを呼び出す

リフレッシュトークン

トークンURLへのPOSTの例

応答

サンプルユースケース

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

サンプルアプリケーションを表示する：モバイルアプリ + API

もっと詳しく