メインコンテンツへスキップ
ネイティブ、モバイル、またはシングルページアプリにログインを追加するには、PKCE を使用する認可コードフローを利用できます。このフローの仕組みと、これを使用すべき理由については、Authorization Code Flow with Proof Key for Code Exchange (PKCE) を参照してください。ネイティブ、モバイル、またはシングルページアプリから API を呼び出す方法については、Call Your API Using Authorization Code Flow with PKCE を参照してください。 PKCE を使用する認可コードフローを実装するには、次のリソースを利用できます。 ログインに成功すると、アプリケーションはユーザーの にアクセスできるようになります。IDトークンには基本的なユーザープロフィール情報が含まれ、アクセストークンは Auth0 の /userinfo エンドポイントや独自の保護された API の呼び出しに使用できます。IDトークンの詳細については、ID Tokens を参照してください。アクセストークンの詳細については、Access Tokens を参照してください。

前提条件

アプリを Auth0 に登録します。詳しくは、ネイティブアプリケーションを登録するまたはシングルページ Web アプリケーションを登録するを参照してください。
  • アプリケーションの種類に応じて、Application TypeNative または Single-Page App を選択します。
  • Allowed Callback URLYOUR_CALLBACK_URL を追加します。コールバック URL の形式は、アプリケーションの種類とプラットフォームによって異なります。アプリケーションの種類およびプラットフォームごとの形式について詳しくは、Native/Mobile クイックスタートおよびSingle-Page App クイックスタートを参照してください。
  • アプリケーションの Grant Types認可コード が含まれていることを確認します。詳しくは、Grant Types を更新するを参照してください。

code verifier を作成

code_verifier を作成します。これは、後でトークンをリクエストするために Auth0 に送信する、暗号学的にランダムな Base64 エンコード文字列です。 code_verifier の作成アルゴリズムの詳細については、 Proof Key for Code Exchange 仕様のセクション 4.1 Client Creates a Code Verifier を参照してください。

Javascript のサンプル

Java の例

Android のサンプル

Swift 5 のサンプル

Objective-C のサンプル

code チャレンジを作成

authorization_code をリクエストするために Auth0 に送信する code_challenge を、code_verifier から生成します。 code_challengecode_verifier からどのように導出されるかについて詳しくは、OAuth Proof Key for Code Exchange 仕様のセクション 4.2 Client Creates the Code Challenge を参照してください。

JavaScript のサンプル

Java のサンプル

Swift 5 サンプル

Objective-C のサンプル

ユーザーの認可を取得する

ユーザーに認可を求め、authorization_code を付けてアプリへリダイレクトして戻します。 code_verifiercode_challenge を作成したら、次にユーザーの認可を取得する必要があります。これは技術的には の開始にあたり、このステップには次のプロセスのうち 1 つ以上が含まれる場合があります。
  • ユーザーを認証する。
  • 認証を処理するため、ユーザーを にリダイレクトする。
  • アクティブな シングルサインオン (SSO) セッションを確認する。
  • 以前に同意が得られていない場合は、要求された権限レベルに対するユーザーの同意を取得する。
ユーザーを認可するには、アプリからユーザーを 認可 URL に送る必要があります。その際、前の手順で生成した code_challenge と、code_challenge の生成に使用したメソッドを含めます。

認可 URL の例

パラメーター

例として、アプリにログインを追加する際の認可 URL 用 HTML スニペットは次のようになります。

レスポンス

正常に処理されると、HTTP 302 レスポンスが返されます。認可コードは URL の末尾に含まれます。

トークンを取得する

authorization_codecode_verifier をトークンに交換します。 認可コードを取得したら、それをトークンに交換する必要があります。前の手順で取得した認可コード (code) を使用して、code_verifier とともに トークンURLPOST リクエストを送信します。

トークンURLにPOSTする例

パラメーター

レスポンス

正常に処理されると、access_tokenrefresh_tokenid_token、および token_type の各値を含むペイロードを伴う HTTP 200 レスポンスを受け取ります。
トークンは保存する前に検証してください。方法については、IDトークンを検証するおよびアクセストークンを検証するを参照してください。
IDトークンには、デコードして取り出す必要があるユーザー情報が含まれています。 アクセストークンは、Auth0 Authentication API の /userinfo エンドポイントまたは別の API を呼び出すために使用します。独自の API を呼び出す場合、API で最初に行う必要があるのは、アクセストークンを検証することです。 リフレッシュトークンは、以前のアクセストークンまたは IDトークン の有効期限が切れた後に、新しいアクセストークンまたは IDトークン を取得するために使用されます。refresh_token がレスポンスに含まれるのは、offline_access スコープを指定し、Dashboard で API に対して Allow Offline Access を有効にした場合のみです。
リフレッシュトークンを使うと、ユーザーの認証状態を実質的に無期限で維持できるため、安全に保存する必要があります。

使用例

Basic認証リクエスト

この例は、手順 1 でユーザーを認証する際に送信できる最も基本的なリクエストを示しています。Auth0 のログイン画面が表示され、ユーザーは設定済みの任意の接続でサインインできます。 ここでトークンをリクエストすると、IDトークンには最も基本的なクレームが含まれます。IDトークンをデコードすると、次のようになります。

ユーザーの名前とプロフィール画像をリクエストする

通常の認証に加えて、この例では、名前やプロフィール画像などの追加のユーザー情報をリクエストする方法を示します。 ユーザーの名前とプロフィール画像をリクエストするには、ユーザーの認可時に適切なスコープを追加する必要があります。 これで、トークンをリクエストすると、IDトークンに要求したnameおよびpictureクレームが含まれるようになります。IDトークンをデコードすると、次のようになります。

GitHub を使ってユーザーをログインさせる

通常のユーザー認証に加え、この例では GitHub などのソーシャル IDプロバイダーにユーザーを直接リダイレクトする方法を示します。この例を動作させるには、Auth0 Dashboard > Authentication > Social に移動し、適切な接続を設定する必要があります。接続名は Settings タブで確認します。 ユーザーを GitHub のログイン画面に直接リダイレクトするには、ユーザーを認可する際に connection パラメーターを渡し、その値を接続名 (この場合は github) に設定する必要があります。 トークンをリクエストすると、IDトークンには GitHub から返されたユーザーの一意の ID を含む sub クレームが含まれます。IDトークンをデコードすると、次のような内容になります。

詳しく見る