バックエンドの注意点

通常のWebAuthnセレモニーは引き続きバックエンドが担当します：

• 登録および認証用のチャレンジ生成
• attestationおよびassertionレスポンスの検証
• relying-party IDとチャレンジの検証を徹底
• ブラウザフローと同じ方法でクレデンシャルとカウンターを保存

変わらない点

このプラグインは、既存のWebAuthn code のフロントエンドの形を維持するように設計されています。

• Webでは、実際のブラウザのWebAuthn API に転送します。
• ネイティブ Capacitor では、ネイティブのpasskey APIに裏打ちされた、ブラウザに近いクレデンシャルオブジェクトを返します。
• バックエンドは同じchallengeと検証のpipelineをそのまま維持できます。

Androidでの変更点

Androidのネイティブpasskeyは、ブラウザの信頼モデルと完全に同一ではありません。

• Digital Asset Linksを使うと、Androidでもウェブサイトと同じrelying partyとクレデンシャルエコシステムを共有できます。
• リテラルの clientDataJSON.origin 値は、ウェブサイトのoriginとは異なる場合があります。
• サーバーが以下以外を拒否する場合： https://your-domain, Androidのネイティブアサーションは、パスキー自体が有効であっても失敗する場合があります。

推奨バックエンドルール

Androidネイティブのパスキーをサポートする場合は、同じRP（Relying Party）に対して、想定されるブラウザのオリジンとAndroidアプリのオリジンの両方を許可してください。

これにより以下が可能になります：

• ウェブサイトのブラウザサポート
• Capacitor アプリでのネイティブパスキーサポート
• 同一のRPドメインにおける単一のパスキーエコシステム

JSONセーフな直接呼び出しが必要な場合

バックエンドが既に以下を返している場合： PublicKeyCredentialCreationOptionsJSON と PublicKeyCredentialRequestOptionsJSONブラウザスタイルのshimの代わりに、APIプラグインを直接使用することも可能です：

import { CapacitorPasskey } from '@capgo/capacitor-passkey';

const registration = await CapacitorPasskey.createCredential({
  origin: 'https://signin.example.com',
  publicKey: registrationOptionsFromBackend,
});

const authentication = await CapacitorPasskey.getCredential({
  origin: 'https://signin.example.com',
  publicKey: requestOptionsFromBackend,
});

Backend Notes の続きへ

使用している場合 バックエンドの注意点 認証とアカウントフローを計画するには、これを次と連携させてください @capgo/capacitor-passkey を使用する @capgo/capacitor-passkey の使用におけるネイティブ機能については、 @capgo/capacitor-social-login @capgo/capacitor-social-login の実装の詳細については、 @capgo/capacitor-passkey @capgo/capacitor-passkey の実装詳細については、 @capgo/capacitor-native-biometric @capgo/capacitor-native-biometric の実装の詳細、および 2要素認証 二要素認証の実装の詳細については。