メインコンテンツへスキップ
パスキーは、従来の認証形式（ユーザー名やパスワードなど）よりもフィッシング耐性が高く、より簡単かつ安全なユーザーエクスペリエンスを提供します。パスキーは、FIDO® W3C Web Authentication（WebAuthn）とClient to Authenticator Protocol（CTAP）の仕様をモデルとしています。 Auth0では現在、データベース接続の認証方法としてパスキーをサポートしており、2つの実装方式が用意されています。

始める前に

カスタムドメインを構成するネイティブのパスキーには。始める前に、テナントにカスタムドメインが構成されていることを確認してください。詳細については、「カスタムドメイン」をお読みください。パスキーポリシーを構成するAndroidまたはiOSのアプリケーションにネイティブのパスキーを実装するには、まずAuth0テナントでパスキーポリシーを構成しなければなりません。テナントを準備するには、「パスキーポリシーを構成する」に記載の手順に従います。アプリケーションを準備するPasskey APIを使用するすべてのアプリケーションは、Passkeyの付与を追加して、証明書利用者ID（RP ID）を構成する必要があります。プラットフォームによっては、または。

​
仕組み

Passkey APIは、Auth0 Authentication APIとプラットフォーム固有の資格情報APIを組み合わせて、チャレンジフローをアプリケーションに直接埋め込みます。つまり、ネイティブモバイルアプリでは、iOSまたはAndroidのプラットフォームAPIを使用し、Webアプリケーションでは、WebAuthnブラウザAPIを使用します。これにより、認証を完了させるためにユーザーをブラウザからリダイレクトさせることなく、統合されたサインアップおよびログインエクスペリエンスを構築できます。 以下の例は、パスキーのサインアップフローで新しいユーザーが体験する可能性のあるプロセスを説明しています。
  1. 新しいユーザーがモバイルアプリケーションを起動して、ログイン画面にアクセスします。新しいユーザーであるため、**［サインアップ］**を選択します。
  2. ユーザーが次の画面でメールアドレスを入力し、**［アカウントの作成］**を選択します。
  3. 次に、アプリケーションのパスキーを作成したいかがユーザーに尋ねられます。ユーザーが**［続ける］**を選択して続行します。
  4. パスキーを生成するために、ユーザーは生体認証や他の認証方法（PINの入力など）を使って、デバイスをローカルで認証しなければなりません。
  5. ローカルの認証が完了すると、新しいパスキーがユーザーのデバイスに保存され、iCloudキーチェーンやGoogleパスワードマネージャーなどのパスキープロバイダーと同期されます。
  6. パスキーが保存されると、ユーザーが新規ユーザー登録プロセスを続行して、アカウント登録を完了させます。
このプロセスが完了すると、ユーザーはアプリケーションへの次回のログインで保存済みのパスキーを使って認証することができます。

​
デバイスの設定を構成する

Auth0 Dashboardでデバイスの設定を構成する
  1. アプリケーション > アプリケーションに移動して、アプリケーションを選択します。
  2. ［設定］タブの下部にある**［高度な設定］**を選択します。
  3. **［デバイス設定］**タブを選択します。
  4. **［iOS］**セクションで、Appleからの次のIDを入力します。
    • チームID
    • App ID
  5. **［変更を保存］**を選択します。
  • Auth0は、構成されたチームIDおよびApp IDに基づいて、https://YOUR_CUSTOM_DOMAIN/.well-known/apple-app-site-associationでテナントのカスタムドメイン上のapple-app-site-associationファイルを自動的にホストします。このファイルをご自身でホストする必要はありません。
  • Xcodeで、Associated Domainsのエンタイトルメントを有効にして、次のような形式でカスタムドメインのエントリを追加します：webcredentials:YOUR_CUSTOM_DOMAIN。

​
Passkeyの付与を有効にする

すべてのプラットフォームでPasskeyの付与を有効にするには以下を行います。
  1. アプリケーション > アプリケーションに移動して、アプリケーションを選択します。
  2. ［高度な設定］セクションで、**［付与タイプ］**タブを選択します。
  3. **［パスキー］の付与を有効してから、［変更を保存］**を選択します。
または、Management APIを使用します。 クライアントの更新エンドポイントを呼び出します。
  • grant_typesを更新して、urn:okta:params:oauth:grant-type:webauthnを含めます。
  • ネイティブアプリには、mobileオブジェクトを使用し、必要に応じてiOSおよびAndroidのデバイス設定を指定します。

​
証明書利用者ID（rpId）

異なるアプリケーションタイプまたは異なるサブドメインを持つアプリケーションタイプにおいて単一のパスキーを使用して認証するエンドユーザには、Auth0 Dashboard > テナント設定で、ルートドメインまたは親ドメインに証明書利用者IDを設定します。

​
パスキーフローを実装する

アプリケーションには以下のパスキーフローを定義することができます。
  • サインアップフロー：新しいユーザーがユーザー登録プロセスでパスキーを生成して保存できるようにします。
  • ログインフロー：パスキーに登録済みの既存のユーザーが、ログインプロセスで保存済みのパスキーを使って認証できるようにします。
  • 登録フロー：既存のユーザーが認証後に自分のアカウントにパスキーを追加できるようにします。

​
サインアップフロー

アプリケーションに初めてログインしようとしたときに、ユーザーがパスキーのサインアップフローを始めます。ユーザーが、既存の識別子を提供した場合には、代わりに、ログインフローの完了をユーザーに求めることをお勧めします。そうしないと、アクションが失敗します。
ネイティブパスキー登録は、サインアップ時に同じ接続で、SMS/メールOTP検証が必要な場合サポートされていません。
  1. アプリケーションは、POST /passkey/registerエンドポイントを呼び出して、サインアップチャレンジを開始します。
POST /passkey/register
Content-Type: application/json

{
  "client_id": "YOUR_CLIENT_ID",
  "realm": "OPTIONAL_CONNECTION",
  "user_profile": {
    "email": "user@example.com",
    "name": "John Doe"
  }
},
  • realmを指定しない場合には、テナントにデフォルトのディレクトリが使用されます。
  • デフォルトでは、emailが必須の識別子です。データベース接続でFlexible Identifiersを有効にした場合は、代わりにemail、phone_number、またはusernameの組み合わせを使用することができます。
  1. Auth0は、auth_session IDとともに、パスキーの作成に必要なPublicKeyCredentialCreationOptionsを返します。
{
  "authn_params_public_key": {
    "challenge": "GENERATED_CHALLENGE_FOR_THIS_SESSION",
    "timeout": 60000,
    "rp": {
      "id": "YOUR_CUSTOM_DOMAIN",
      "name": "YOUR_CUSTOM_DOMAIN"
    },
    "pubKeyCredParams": [
      { "type": "public-key", "alg": -8 },
      { "type": "public-key", "alg": -7 },
      { "type": "public-key", "alg": -257 }
    ],
    "authenticatorSelection": {
      "residentKey": "required",
      "userVerification": "preferred"
    },
    "user": {
      "id": "GENERATED_ID",
      "name": "USER_EMAIL",
      "displayName": "USER_EMAIL_OR_NAME"
    }
  },
  "auth_session": "SESSION_ID"
}
  1. アプリケーションは、返されたPublicKeyCredentialCreationOptionsを使用して、ユーザーのデバイスにパスキーを作成します。方法はプラットフォームによって異なります。
ASAuthorizationPlatformPublicKeyCredentialProviderを使用して、Face ID、Touch ID、またはデバイスPINで資格情報を作成します。詳細については、「iOSでの登録に関するドキュメント」をご覧ください。
  1. アプリケーションは、登録プロセスからの資格情報を使用してPOST /oauth/tokenエンドポイントを呼び出し、資格情報をトークンと交換します。
POST /oauth/token
Content-Type: application/json

{
  "grant_type": "urn:okta:params:oauth:grant-type:webauthn",
  "client_id": "YOUR_CLIENT_ID",
  "realm": "OPTIONAL_CONNECTION",
  "scope": "openid profile email",
  "audience": "YOUR_API_IDENTIFIER",
  "auth_session": "SESSION_ID_FROM_STEP_1",
  "authn_response": {
    "id": "BASE64URL_ID",
    "rawId": "BASE64URL_RAWID",
    "type": "public-key",
    "authenticatorAttachment": "platform",
    "response": {
      "clientDataJSON": "BASE64URL_CLIENT_DATA_JSON",
      "attestationObject": "BASE64URL_ATTESTATION_OBJECT"
    }
  }
}
  1. Auth0は新しいユーザーアカウントを作成して、例が示すような要求されたトークンを返します。
{
  "access_token": "eyJz93a...TJVA95w",
  "refresh_token": "GEz...NaYM",
  "id_token": "eyJ0exA...f1jrv3",
  "token_type": "Bearer",
  "expires_in": 86400
}
サインアップフローの呼び出しおよびパラメーターについて詳しくは、「Authentication API Explorer」をご覧ください。

​
ログインフロー

既存のユーザーがアプリケーションにログインしようとしたときに、パスキーのログインフローを始めます。このフローは、既存のユーザーが最初のサインアップでアカウントにパスキーを保存している場合にのみ有効です。
  1. アプリケーションが、POST /passkey/challengeエンドポイントを呼び出し、ログインチャレンジを開始します。
POST /passkey/challenge
Content-Type: application/json

{
  "client_id": "YOUR_CLIENT_ID",
  "realm": "OPTIONAL_CONNECTION"
}
realmを指定しない場合には、テナントにデフォルトのディレクトリが使用されます。
  1. Auth0は、auth_sessionとともにPublicKeyCredentialRequestOptionsを返します。
{
  "authn_params_public_key": {
    "challenge": "GENERATED_CHALLENGE_FOR_THIS_SESSION",
    "timeout": 60000,
    "rpId": "YOUR_CUSTOM_DOMAIN",
    "userVerification": "preferred"
  },
  "auth_session": "SESSION_ID"
}
  1. アプリケーションは、返されたPublicKeyCredentialRequestOptionsを使用して、ユーザーのデバイスからパスキーを取得します。方法はプラットフォームによって異なります。
ASAuthorizationPlatformPublicKeyCredentialProviderを使用して、Face ID、Touch ID、またはデバイスPINで資格情報を取得します。詳細については、「iOSでのログインに関するドキュメント」をご覧ください。
  1. アプリケーションは、ログインプロセスからの資格情報を使用してPOST /oauth/tokenエンドポイントを呼び出し、資格情報をトークンと交換します。
POST /oauth/token
Content-Type: application/json

{
  "grant_type": "urn:okta:params:oauth:grant-type:webauthn",
  "client_id": "YOUR_CLIENT_ID",
  "realm": "OPTIONAL_CONNECTION",
  "scope": "openid profile email",
  "audience": "YOUR_API_IDENTIFIER",
  "auth_session": "SESSION_ID_FROM_STEP_1",
  "authn_response": {
    "id": "BASE64URL_ID",
    "rawId": "BASE64URL_RAWID",
    "type": "public-key",
    "authenticatorAttachment": "platform",
    "response": {
      "authenticatorData": "BASE64URL_AUTHENTICATORDATA",
      "clientDataJSON": "BASE64URL_CLIENTDATAJSON",
      "signature": "BASE64URL_SIGNATURE",
      "userHandle": "BASE64URL_USERHANDLE"
    },
    "clientExtensionResults": {}
  }
}
  1. Auth0が、資格情報を認証して要求されたトークンを返します。
{
  "access_token": "eyJz93a...TJVA95w",
  "refresh_token": "GEz...NaYM",
  "id_token": "eyJ0exA...f1jrv3",
  "token_type": "Bearer",
  "expires_in": 86400
}
ログインフローの呼び出しおよびパラメーターについて詳しくは、「Authentication API Explorer」をご覧ください。

​
登録フロー

登録フローでは、ユーザーがユーザー名やパスワードなど別の方法で認証されていると、自分のアカウントにパスキーを追加できます。認証済みの既存ユーザーが新しいパスキーを登録する場合は、My Account APIを使用します。

始める前に

登録フローを開始する前に、以下を行います。
  1. テナントでMy Account APIを有効にします
  2. /meエンドポイントのcreate:me:authentication_methodsスコープを持つアクセストークンを取得します。
完全なセットアップ手順については、「My Account API」をお読みください。
  1. 認証済みのアプリケーションが、アクセストークンを使用して、POST /me/v1/authentication-methodsエンドポイントを呼び出します。
POST /me/v1/authentication-methods
Authorization: Bearer YOUR_ACCESS_TOKEN
Content-Type: application/json

{
  "type": "passkey",
  "connection": "CONNECTION_NAME"
}
  1. Auth0は、チャレンジおよびセッションIDを返します。
{
  "authn_params_public_key": {
    "challenge": "GENERATED_CHALLENGE",
    "timeout": 60000,
    "rp": {
      "id": "YOUR_CUSTOM_DOMAIN",
      "name": "YOUR_CUSTOM_DOMAIN"
    },
    "pubKeyCredParams": [
      { "type": "public-key", "alg": -8 },
      { "type": "public-key", "alg": -7 },
      { "type": "public-key", "alg": -257 }
    ],
    "authenticatorSelection": {
      "residentKey": "required",
      "userVerification": "preferred"
    },
    "user": {
      "id": "GENERATED_ID",
      "name": "USER_IDENTIFIER",
      "displayName": "USER_DISPLAY_NAME"
    }
  },
  "auth_session": "SESSION_ID"
}
  1. アプリケーションが、返されたPublicKeyCredentialCreationOptionsを使用して、サインアップフローと同様のプラットフォーム固有の手順に従って、ユーザーのデバイスにパスキーを作成します。
ASAuthorizationPlatformPublicKeyCredentialProviderを使用して、Face ID、Touch ID、またはデバイスPINで資格情報を作成します。詳細については、「iOSでの登録に関するドキュメント」をご覧ください。
  1. ユーザーがAuthenticatorでパスキーを作成した後、POST /me/v1/authentication-methods/passkey|new/verifyエンドポイントを呼び出し、登録を完了させます。
POST /me/v1/authentication-methods/passkey|new/verify
Authorization: Bearer YOUR_ACCESS_TOKEN
Content-Type: application/json

{
  "auth_session": "SESSION_ID_FROM_STEP_1",
  "authn_response": {
    "id": "BASE64URL_ID",
    "rawId": "BASE64URL_RAWID",
    "type": "public-key",
    "authenticatorAttachment": "platform",
    "response": {
      "clientDataJSON": "BASE64URL_CLIENT_DATA_JSON",
      "attestationObject": "BASE64URL_ATTESTATION_OBJECT"
    }
  }
}
この手順が正常に完了すると、パスキーはユーザーに登録され、今後の認証で使用できるようになります。 登録フローの呼び出しおよびパラメーターについて詳しくは、「My Account API Explorer」をご覧ください。

​
証明書利用者ID

使用するアプリケーションの1つで作成されたパスキーは、その他のアプリケーション、ネイティブアプリケーション、またはWebアプリケーションが同一の証明書利用者ID（rpId）を共有する場合、これらにサインインするために使用できます。この仕組みが機能するのは、パスキープロバイダー（iCloudキーチェーン、Googleパスワードマネージャー、1Password、Dashlaneなど）が同一プロバイダー内にあるユーザーのデバイスにおいて資格情報を同期するからです。

​
プラットフォーム間でユーザーを移行する

ほとんどの場合、ユーザーはQRコードを読み取ったり、別のデバイスを使ったりする必要はありません。使用しているデバイスでパスキーがすでに存在するかどうかによって、フローは異なります。
  • 同一プロバイダー、異なるデバイス（最も一般的）：ユーザーがiOSアプリでパスキーを登録すると、iCloudキーチェーンによってパスキーがMacに同期されます。その結果、ユーザーはMac上のWebアプリに即座にサインインできます。同様に、Androidで登録したパスキーは、Googleパスワードマネージャーを通じて、同じGoogleアカウントでサインインしているChromebookやWindows PCのChromeに同期されます。
  • クロスエコシステムまたは共有デバイス（あまり一般的ではない）：ユーザーが使用中のデバイスでパスキーを利用できない場合（例：iPhoneにあるパスキーをWindows PCで使う、公衆の共有PCを使う）、ブラウザはQRコードによる認証を提示します。これはハイブリッドトランスポート（CTAP 2.2）を使用して、ユーザーのスマートフォン経由で認証を行う仕組みです。ユーザーは自分のパスキーをスマートフォンに保持したままで、QRコードはその1回のサインインのためだけに、2つのデバイスを橋渡しします。

​
証明書利用者IDを選択する

rpIdは、パスキーを使用できるオリジンを決定します。Auth0は、デフォルトでrpIdをカスタムドメインに設定します。パスキーを機能させるスコープに最も適したrpIdを選択します。それ以上に広げません。 推奨：auth.example.comやaccounts.example.comなど、認証領域および製品領域にスコープを定義する親ドメインを使用します。“rpId=auth.example.comで作成されたパスキーは、auth.example.comおよびそのサブドメイン（例：app.auth.example.com、m.auth.example.com）上で機能します。 **eTLD+1（registrable apex）をrpId**として使用することは避けます（例：example.com）。このレベルでrpIdを設定すると、example.comのすべてのサブドメインが、マーケティングサイト、サードパーティがホストするサービス、または他のチームによって運用されるドメインを含めて、それらのパスキーをリクエスト、使用できてしまいます。これにより、信頼境界が認証領域を大きく超えて広がります。 証明書利用者IDについて詳しくは、「RP IDの詳細」をお読みください。

​
マルチドメインとブランドのシナリオ

複数のブランドドメイン（例：login.brand1.comとlogin.brand2.com）を提供する場合、パスキーはそれらを跨いで自動的に機能しません。つまり、ドメインごとに、独自のrpIdがあります。ドメインごとの登録、通信、移行のパターンについては、「マルチカスタムドメインを使用するパスキー」をお読みください。

​
構成チェックリスト

rpIdを選択したら、すべてのアプリケーションで共有されていることを確認します。
  1. パスキーを共有する必要のあるネイティブアプリケーションおよびWebアプリケーションのすべてで、rpIdとしてカスタムドメインを1つ使用します。
  2. ネイティブアプリケーションでは、iOSのチームID/App ID、およびAndroidのパッケージ名/SHA-256フィンガープリントを使用して、Auth0 Dashboardで［デバイス設定］を構成します。Auth0は、カスタムドメイン上のapple-app-site-associationおよびassetlinks.jsonファイルを自動的にホストします。
  3. Webアプリケーションでは、rpIdまたはそのサブドメインからWebオリジンを提供して、CORSの**［許可するWebオリジン］**に追加します。

​
参考情報

アプリケーションにパスキー認証を実装する際には、以下のリソースを参考にすることができます。