- Web アプリケーション向けの Universal Login パスキー。
- Nativeモバイルアプリケーション (iOS、Android) および Web アプリケーション向けの Passkey API。
- Web および Nativeアプリケーション向けの埋め込みログイン
開始する前に
カスタムドメインを設定するNativeパスキーを使用するには、が必要です。続行する前に、テナント用のカスタムドメインを設定済みであることを確認してください。詳細については、カスタムドメインを参照してください。パスキーポリシーを設定するAndroid または iOS アプリケーションに Nativeパスキーを実装するには、Auth0 テナントでパスキーポリシーを設定する必要があります。テナントを準備するには、パスキーポリシーの設定の手順に従ってください。アプリケーションを準備するPasskey API を使用するすべてのアプリケーションでは、
Passkey グラントを追加し、Relying Party ID (RP ID) を設定する必要があります。プラットフォームによっては、またはで追加設定が必要になる場合もあります。仕組み
- 新規ユーザーがモバイルアプリケーションを起動し、ログイン画面を開きます。新規ユーザーのため、Sign Up を選択します。
- 次の画面で、ユーザーはメールアドレスを入力し、Create Account を選択します。
- 次に、アプリケーション用のパスキーを作成するかどうかをユーザーに尋ねます。続行するには、Continue を選択します。
- パスキーを生成するには、ユーザーは生体認証や PIN の入力などの認証方法で、デバイス上でローカル認証を行う必要があります。
- ローカル認証が完了すると、新しいパスキーがユーザーのデバイスに保存され、iCloud Keychain や Google Password Manager などのパスキープロバイダーと同期されます。
- パスキーが保存されると、ユーザーは新規ユーザー登録プロセスを続行してアカウントを確定します。
デバイス設定を構成する
- iOS
- Android
- Web
Auth0 Dashboard でデバイス設定を構成する:
- アプリケーション > アプリケーション に移動し、アプリケーションを選択します。
- Settings タブの下部にある Advanced Settings を選択します。
- Device Settings タブを選択します。
- iOS セクションで、Apple の以下の ID を入力します。
- Team ID
- App ID
- 変更を保存 を選択します。
-
Auth0 は、設定した Team 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 グラントを有効にするには、次の手順を実行します。
- アプリケーション > アプリケーションに移動し、対象のアプリケーションを選択します。
- Advanced Settingsセクションで、Grant Types タブを選択します。
- Passkey グラントを有効にして、変更を保存 を選択します。
grant_typesにurn:okta:params:oauth:grant-type:webauthnを追加します。- Nativeアプリでは、必要に応じて
mobileオブジェクトを使用し、iOSおよびAndroidのデバイス設定を指定します。
Relying party ID (rpId)
パスキーフローを実装する
- Signup flow:新規ユーザーがユーザー登録時にパスキーを生成して保存できるようにします。
- ログインフロー:すでにパスキーを登録している既存ユーザーが、ログインプロセス中に保存済みのパスキーで認証できるようにします。
- 登録フロー:既存ユーザーが認証後にアカウントにパスキーを追加できるようにします。
サインアップフロー
- アプリケーションは、
POST /passkey/registerエンドポイントを呼び出してサインアップチャレンジを開始します。
realmを指定しない場合は、テナントのデフォルトディレクトリが使用されます。- デフォルトでは、
emailが必須の識別子です。データベース接続でFlexible Identifiersを有効化している場合は、email、phone_number、usernameを組み合わせて使用できます。
- Auth0は、パスキーの作成に必要な
PublicKeyCredentialCreationOptionsとauth_sessionIDを返します。
- アプリケーションは、返された
PublicKeyCredentialCreationOptionsを使用して、ユーザーのデバイスにパスキーを作成します。作成方法はプラットフォームによって異なります。
- iOS
- Android
- Web
ASAuthorizationPlatformPublicKeyCredentialProvider を使用して、Face ID、Touch ID、またはデバイスの PIN で資格情報を作成します。詳細については、iOS の登録に関するドキュメントを参照してください。- アプリケーションは、登録プロセスで取得した資格情報を使用して
POST /oauth/tokenエンドポイントを呼び出し、資格情報をトークンと交換します。
- Auth0 は新しいユーザーアカウントを作成し、以下の戻り値の例に示すように、要求されたトークンを返します。
ログインフロー
- アプリケーションは、ログインチャレンジを開始するために
POST /passkey/challengeエンドポイントを呼び出します。
realmを指定しない場合は、テナントのデフォルトディレクトリが使用されます。- Auth0 は
PublicKeyCredentialRequestOptionsとauth_sessionを返します。
- アプリケーションは、返された
PublicKeyCredentialRequestOptionsを使用して、ユーザーのデバイスからパスキーを取得します。方法はプラットフォームによって異なります。
- iOS
- Android
- Web
ASAuthorizationPlatformPublicKeyCredentialProvider を使用して、Face ID、Touch ID、またはデバイスの PIN で資格情報を取得します。詳細については、iOS のログインに関するドキュメントを参照してください。- アプリケーションは、ログインプロセスで取得した資格情報を使用して
POST /oauth/tokenエンドポイントを呼び出し、資格情報をトークンと交換します。
- Auth0 は資格情報を認証し、要求されたトークンを返します。
登録フロー
開始する前に
登録フローを開始する前に、次のことを確認してください。
- テナントの My Account API を有効化します。
/meエンドポイント用のcreate:me:authentication_methodsスコープを持つアクセストークンを取得します。
- 認証済みのアプリケーションから、アクセストークンを使用して
POST /me/v1/authentication-methodsエンドポイントを呼び出します。
- Auth0 はチャレンジとセッション ID を返します。
- アプリケーションは、サインアップフローと同じプラットフォーム固有の手順に従って、返された
PublicKeyCredentialCreationOptionsを使用し、ユーザーのデバイスにパスキーを作成します。
- iOS
- Android
- Web
ASAuthorizationPlatformPublicKeyCredentialProvider を使用して、Face ID、Touch ID、またはデバイスの PIN で資格情報を作成します。詳細については、iOS の登録に関するドキュメントを参照してください。- ユーザーが認証器を使用してパスキーを作成した後、
POST /me/v1/authentication-methods/passkey|new/verifyエンドポイントを呼び出して登録を完了します。
Relying party ID
rpId) を共有する他のアプリケーション (Native または Web アプリケーション) へのサインインにも使用できます。これは、パスキープロバイダー (iCloud Keychain、Google Password Manager、1Password、Dashlane など) が、同一プロバイダー内でユーザーのデバイス間の資格情報を同期するためです。
プラットフォーム間でユーザーを移行する
- 同じプロバイダーで異なるデバイス (最も一般的) :ユーザーが iOS アプリでパスキーを登録すると、iCloud Keychain によってそのパスキーが Mac に同期され、すぐにウェブアプリにサインインできます。同様に、同じ Google アカウントにログインしている Chromebook または Windows PC の Chrome では、Google Password Manager 経由で同期された Android のパスキーを使用できます。
- 異なるエコシステム間または共有デバイスの場合 (比較的まれ) :使用中のデバイスでパスキーを利用できない場合 (たとえば、Windows PC で iPhone のパスキーを使用する場合や、公共のコンピューターを使用する場合) 、ブラウザーはハイブリッドトランスポート (CTAP 2.2) を使用してユーザーの電話で認証するための QR コードを表示します。パスキーはユーザーの電話に保持され、QR コードはその 1 回のサインイン時に限り、2 台のデバイスをつなぐ役割を果たします。
Relying Party 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 (登録可能な最上位ドメイン) を rpId として使用しないでください — たとえば、example.com です。このレベルで rpId を設定すると、マーケティングサイト、サードパーティがホストするサービス、他のチームが運用するドメインを含め、example.com のすべてのサブドメインがこれらのパスキーをリクエストして使用できるようになります。これにより、信頼境界が認証画面をはるかに超えて広がります。
Relying Party IDの詳細については、RP ID Deep Diveを参照してください。
複数ドメインおよびブランドのシナリオ
login.brand1.com と login.brand2.com) を使用している場合、パスキーはドメイン間で自動的に機能するわけではありません。各ドメインにはそれぞれ固有の rpId があります。ドメインごとの登録、ユーザーへの案内、移行パターンについては、複数のカスタムドメインでのパスキーを参照してください。
設定チェックリスト
rpId を選択したら、すべてのアプリケーションで同じものを使用していることを確認してください。
- パスキーを共有するすべての Native および Web アプリケーションで、1 つのカスタムドメインを
rpIdとして使用します。 - Nativeアプリケーションでは、Auth0 Dashboard の デバイス設定 で iOS Team ID/App ID と Android パッケージ名/SHA-256 フィンガープリントを設定します。Auth0 は、カスタムドメインで
apple-app-site-associationファイルとassetlinks.jsonファイルを自動的にホストします。 - Web アプリケーションでは、Web オリジンを
rpIdまたはそのサブドメインから提供し、CORS 用に Allowed Web Origins に追加します。
詳細情報
-
Auth0 API
- Authentication API: パスキー認証のエンドポイントを確認します。
- My Account API: パスキー登録のエンドポイントについて確認します。
- My Account API ドキュメント: 有効化、スコープ、CORS について確認します。
- プラットフォームドキュメント
-
追加リソース
- passkeys.dev: パスキー実装に関する包括的なガイド。