ネイティブやモバイル、シングルページのアプリケーションにログインを追加するのに、PKCEを使った認可コードフローを活用することができます。フローの仕組みやメリットについては、「Proof Key for Code Exchange（PKCE）を使った認可コードフロー 」をお読みください。ネイティブやモバイル、シングルページのアプリケーションからAPIを呼び出す方法については、「PKCEを使った認可コードフローで独自のAPIを呼び出す 」をお読みください。
Proof Key for Code Exchange（PKCE）を使った認可コードフローを実装するには、以下のリソースを使用することができます。
ログインに成功すると、アプリケーションがユーザーのIDトークンとアクセストークンにアクセスします。IDトークンには基本的なユーザープロファイル情報が含まれています。アクセストークンはAuth0の/userinfoエンドポイントや独自の保護されたAPIを呼び出すのに使用することができます。IDトークンの詳細については、「IDトークン 」をお読みください。アクセストークンの詳細については、「アクセストークン 」をお読みください。
前提条件 アプリをAuth0に登録する必要があります。詳細については、「ネイティブアプリケーションを登録する 」または「シングルページWebアプリケーションを登録する 」をお読みください。
アプリケーションタイプに応じて、［Native（ネイティブ）］ または ［Single-Page App（シングルページアプリ）］ の ［Application Type（アプリケーションタイプ）］ を選択します。
YOUR_CALLBACK_URLの ［Allowed Callback URL（許可されているコールバックURL）］ を追加します。コールバックURLの形式は、使用しているアプリケーションタイプとプラットフォームによって異なります。アプリケーションタイプの形式とプラットフォームの詳細については、「Mobile/Native Quickstarts 」と「Single-Page App Quickstarts 」を参照してください。アプリケーションの ［Grant Types（付与タイプ）］ に ［Authorization Code（認可コード）］ が必ず含まれていることを確認してください。詳細については、「付与タイプを更新する 」をお読みください。
コードベリファイアを作成する code_verifierを作成します。これは、トークンを要求するために最終的にAuth0に送信される、暗号的にランダムなBase64でエンコードされたキーです。code_verifierを作成するアルゴリズムの詳細については、OAuth 4.1 Client Creates a Code Verifier（クライアントがコード検証を作成） 」セクションをお読みください。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のサンプル // 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 . 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を生成します。code_challengeがcode_verifierからどのように派生するかの詳細については、OAuth Proof Key for Code Exchange仕様の「4.2 Client Creates the 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, 0x 0 , 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: @"=" ]]; ユーザーを認可する ユーザーの認可を要求すると、authorization_codeでアプリにリダイレクトされます。
code_verifierとcode_challengeを作成したら、ユーザーの認可を取得する必要があります。技術的には、これが認可フローの始まりとなります。この手順には以下のようなプロセスが含まれます：* ユーザーを認証する。
* 認証を行うために、ユーザーをIDプロバイダーへリダイレクトする。
* アクティブなシングルサインオン（SSO） セッションを確認する。
* 以前に同意を得ていない場合は、要求された権限レベルについてユーザーの同意を得る。
ユーザーを認可するために、アプリは前のステップで生成したcode_challengeとcode_challengeの生成に使用したメソッドを含め、ユーザーを認可URL に送信する必要があります。
認可URLの例 パラメーター パラメーター名 説明 response_typeAuth0が返す資格情報の種類を示します（codeまたはtoken）このフローでは、値はcodeでなければなりません。 code_challengecode_verifierから生成されたチャレンジ。code_challenge_methodチャレンジを生成するために使用されるメソッド（例、S256）。PKCE仕様はS256とplainの2つのメソッドを定義します。S256はこの例で使用されておりAuth0がサポートしている唯一 のものであるため、plainは推奨されていません。 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にメンバーを招待する 場合、ユーザーが招待を受け入れたとき、アプリケーションは、invitationおよびorganizationのキー/値ペアを転送することで、招待の受け入れを処理する必要があります。
たとえば、アプリにログインを追加する際の認可URLのHTMLスニペットは、以下のようになります。
Response （レスポンス） すべてが成功すると、HTTP 302応答を受け取ります。認可コードはURLの末尾に含まれます：
HTTP/1.1 302 Found Location: {yourCallbackUrl}?code={authorizationCode}&state=xyzABC123 トークンを要求する authorization_codeとcode_verifierをトークンと交換します。取得した認可コードは、トークンと交換する必要があります。前の手順で抽出した認可コード（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エンコードする必要があります。
Response （レスポンス） すべてが成功すると、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トークン には、デコードして抽出する必要があるユーザー情報が含まれています。アクセストークン は、Auth0認証APIの/userinfoエンドポイント または別のAPIを呼び出すために使用されます。独自のAPIを呼び出す場合にAPIが最初に行うのは、アクセストークンを検証 することです。リフレッシュトークン は、アクセストークンまたはIDトークンの期限が切れたときに、新しいトークンの取得に使用されます。refresh_tokenは、offline_accessスコープを含め、DashboardでAPIの ［Allow Offline Access（オフラインアクセスの許可）］ を有効にした場合にのみ、応答内に表示されます。リフレッシュトークンは、ユーザーが実質的に永久に認証された状態を維持できるようにするため、安全に保管しなければなりません。
ユースケース 基本的な認証要求 この例では、手順1でユーザーを認可する際に行う最も基本的な要求について説明します。Auth0のログイン画面を表示して、構成されている接続でユーザーがサインインできるようにします。
トークンを要求する際に、IDトークンには最も基本的なクレームが含まれます。IDトークンをデコードする際には、以下のようになります。
{ "iss" : "https://auth0pnp.auth0.com/" , "sub" : "auth0|581..." , "aud" : "xvt9..." , "exp" : 1478112929 , "iat" : 1478076929 } ユーザーの名前とプロファイルの写真を要求する 通常のユーザー認証に加えて、この例では名前や写真など、追加のユーザー詳細情報を要求する方法について説明します。
ユーザーの名前や写真を要求するには、ユーザーを認可する際に、適切なスコープを追加する必要があります。
トークンを要求する際に、IDトークンには要求された名前と写真のクレームが含まれます。IDトークンをデコードする際には、以下のようになります。
{ "name" : "auth0user@..." , "picture" : "https://example.com/profile-pic.png" , "iss" : "https://auth0user.auth0.com/" , "sub" : "auth0|581..." , "aud" : "xvt..." , "exp" : 1478113129 , "iat" : 1478077129 } GitHubでのユーザーログインを要求する 通常のユーザー認証に加えて、この例では、ユーザーをGitHubなどのソーシャルIDプロバイダーへ直接送る方法について説明します。この例を利用するには、［Auth0 Dashboard］ > ［Authentication（認証）］ > ［Social（ソーシャル）］ に移動して、適切な接続を構成する必要があります。［Settings（設定）］ タブから接続名を取得します。
ユーザーをGitHubのログイン画面へ直接送るには、connectionパラメーターを渡して、ユーザー認可時にその値を接続名（この場合はgithub）に設定します。
トークンを要求する際に、IDトークンにはGitHubから返されたユーザーの一意のIDを含むsubクレームが含まれます。IDトークンをデコードする際には、以下のようになります。
{ "name" : "John Smith" , "picture" : "https://avatars.example.com" , "email" : "jsmith@..." , "email_verified" : true , "iss" : "https://auth0user.auth0.com/" , "sub" : "github|100..." , "aud" : "xvt..." , "exp" : 1478114742 , "iat" : 1478078742 } もっと詳しく 
