ごきげんよう、IDチームのわかなです！
今回は、Okta Identity Engine (OIE) の環境向けに早期アクセスでリリースされた新機能、「Passkeys リブランド機能」について、検証してみました。
これまで「FIDO2 (WebAuthn)」と呼ばれていたAuthenticatorが、「Passkeys (FIDO2 WebAuthn)」に名称変更され、管理画面の統合や「パスキーでサインイン」ボタンの追加など、管理者・エンドユーザー双方に嬉しいアップデートが入っています。
Google Titan Security Keyを使って、登録からサインインまで実際に試してみたので、設定方法・ユーザー体験・注意点をまとめます。
そもそもパスキーとは？
パスキー（Passkey）とは
FIDO2 Web Authentication（WebAuthn）標準に基づく認証資格情報のことです。パスワードの代わりに、公開鍵暗号方式を使ってサインインします。
従来のパスワードやワンタイムパスコード（OTP）と違い、フィッシング耐性が高いのが最大の特徴です。認証情報は特定のドメインに暗号的に紐づくため、ドメイン偽装した偽物のサイトでは使えません。
Synced Passkeys と Device-bound Passkeys
パスキーには大きく2種類あります。
| 種類 | 説明 | 例 |
|---|---|---|
| Synced Passkeys（同期パスキー） | iCloud KeychainやGoogle Password Managerなどのクラウドサービスを通じて複数デバイスに同期される | iPhone Face ID、Mac Touch ID、Android生体認証 |
| Device-bound Passkeys（デバイスバウンドパスキー） | 特定のハードウェアに固定され、エクスポート不可 | Google Titan、YubiKey 等のセキュリティキー |
Discoverable Credential（Resident Key）とは
パスキーの重要な特性としてDiscoverable Credential（発見可能な資格情報）があります。これは認証器側にユーザーIDを保存する仕組みで、ユーザー名を入力せずにサインインできる「ユーザー名レス認証」を実現します。
「パスキーの作成」設定をONにすると、常にこのDiscoverable Credentialが生成されるようになります。
管理者画面は何が変わった？
では実際にOktaの管理画面で確認していきましょう！
まずはEarly Access機能の有効化
Settings（設定） > Features（機能） から、「Passkeys Rebrand」を有効にします。
新しい設定ページの解説
有効化前後で Security（セキュリティ） > Authenticators の表示が変わります。
- FIDO2 (WebAuthn)からPasskeys (FIDO2 WebAuthn)に！
- 設定画面が統合しAAGUIDリストなどタブ移動できるように
- エンドユーザーエクスペリエンスで「パスキーでサインイン」ボタンをカスタマイズ
- 証明書ベースの認証補完、ハードウェア保護、FIPS準拠 のチェックボックス追加
パスキーの作成トグル
パスキーの作成セクションに新しく追加されたトグルです。
| 設定 | 動作 |
|---|---|
| ON | 常にDiscoverable Credential（パスキー）を生成。エンドユーザーエクスペリエンスのパスキー機能が利用可能に。 |
| OFF | パスキーとレガシーU2Fクレデンシャルが混在。 |
ユーザー検証
登録時と認証時での要件が別々に設定可能となりました。
| オプション | 登録時の動作 | 認証時の動作 |
|---|---|---|
| 必須 | 指紋・顔・PINが必須。デバイスが非対応なら登録失敗。 | 毎回生体認証/PINが必須 |
| 推奨 | 対応していれば求める、非対応でも登録可。 | 対応していれば求める、非対応でもサインイン可 |
| 非推奨 | 検証を求めない。他のステップで十分な場合のみ使用。 | 検証を求めない |
💡 例えば、Google Titanで必須の場合はPINの入力とタッチの両方で検証が行われます。
エンドユーザーエクスペリエンスのカスタマイズ
- Authenticator名：パスキーの名称や説明を自由に編集できます
- パスキーボタンでサインイン：サインインページにFastPassのようにパスキーを使うボタンが表示されます
- パスキー自動入力：有効にすると、エンドユーザーがユーザー名を入力して「次へ」を押した後、ブラウザがパスキーによる認証を自動的に求めます。キャンセルしない限り他の認証方法（パスワード、OTP、プッシュ通知など）を選べないため、パスキーが最優先の認証手段として動作します。
エンドユーザー体験の検証
ここからは実際にGoogle Titanを使ってエンドユーザーの体験を見ていきます！
パスキー登録フロー
- ダッシュボードにサインイン
- Settings（設定） > Security Methods（セキュリティ方式） に移動
- 「セキュリティキーまたは生体認証Authenticator」をクリック
- Google Titanを挿入（USB）またはかざす（NFC）
- PINの入力とタッチで登録完了
新しいサインイン画面
リブランド後、サインイン画面に「パスキーでサインイン」ボタン が表示されます。
- Oktaのサインイン画面にアクセス
- 画面下部の「パスキーでサインイン」をクリック
- Google Titanの挿入を求められる
- PINの入力とタッチで認証
- ユーザー名を入力せずにサインイン完了！ 🎉
ユーザー名もパスワードも入力せずにサインインできました！！！
パスキー自動入力の動作
パスキー自動入力を有効にしている場合、ユーザー名を入力し次へを押すとパスキーが表示されます。
キャンセルを押さないと「パスワード」「OTP」や「プッシュ通知」でサインインを選択できないため、エンドユーザーへの案内としては、セキュリティキーを使う場合は「パスキーでサインイン」ボタンのみを設定する方が直感的で分かりやすいです。
検証で見つけた注意点・ハマりポイント
RP ID変更時は全パスキーが無効化される
カスタムドメインを設定しているorgでは、Relying Party ID（RP ID）をカスタマイズできます。ただし、RP IDを変更・アクティブ化すると、既存のパスキーがすべて無効になり、ユーザーは再登録が必要です。 RP IDを変更する場合は、事前にユーザーへ通知し、再登録の手順を案内しましょう。
Global Session Policyの設定がパスキー自動入力に影響する
Global Session Policyの「次を使用してユーザーセッションを確立」が 「パスワード」 になっていると、パスキー自動入力が動作しませんでした。公式ドキュメントでも「Sign-In Widgetでパスワード優先フローを使用している場合には、パスキーの自動入力は機能しません。」と記載があるため、パスキー自動入力を使いたい場合は先に「認証ポリシーの要件を満たすために使用される任意の要素」に変更する必要があります。
登録時のブラウザダイアログ
パスキー登録時、Chromeでは「パスキーを保存する場所を選んでください」というダイアログが表示され、Google パスワードマネージャー、iCloudキーチェーン、セキュリティキーなどが候補に出ます。 エンドユーザーへの案内時に 「スマートフォン、タブレット、またはセキュリティキー」を選んでください と明示すると迷わずに済みます。
Okta FastPassとの差別化
「パスキーでサインイン」ボタンと「Okta FastPassでサインインする」ボタンは サインイン画面に並列表示 されます。どちらもパスワードレス認証を実現する手段ですが、位置づけが異なります。
| 項目 | パスキー（FIDO2 WebAuthn） | Okta FastPass |
|---|---|---|
| 必要なもの | セキュリティキー or パスキー対応デバイス | Okta Verifyアプリ |
| デバイス依存 | セキュリティキーならデバイス非依存。どのPCでも使える | Okta Verifyをインストールしたデバイスに依存 |
| デバイス保証 | FIDO MDS/AAGUIDでの認証器制御が可能 | Device Trust / デバイス保証ポリシーと連携 |
| ユーザー名入力 | 不要（Discoverable Credential） | 不要（Okta Verifyが保持） |
| フィッシング耐性 | あり（FIDO2標準） | あり（Okta独自実装） |
| オフライン認証 | 不可 | 不可 |
| 管理コスト | セキュリティキーの配布・紛失対応が必要 | Okta Verifyの展開・管理が必要 |
- FastPass向き：Okta Verifyを全社展開済みの環境。デバイス保証と組み合わせてマネージドデバイスからのアクセスを制御したい場合。
- パスキー向き：共有端末やキオスク端末などOkta Verifyを入れられない環境。または外部の協力会社など、自社MDM管理外のユーザーにフィッシング耐性認証を提供したい場合。
- 併用：FastPassをメイン、パスキーをバックアップ（FastPassが使えない状況用）として設計するパターン。
まとめ
今回のPasskeysリブランドは「名前が変わっただけ」ではなく、以下の実質的な改善がセットになっています。
- 管理画面の統合：資格情報の設定・エンドユーザーエクスペリエンス・アクセス制御が1ページに集約され、タブで切り替え可能に
- 「パスキーでサインイン」ボタン：エンドユーザーがパスキーでサインインする導線がFastPassと並んで明確に
- ユーザー検証の分離：登録時と認証時で別々にポリシー設定可能に（旧画面では1つの設定だった）
- パスキー自動入力：スムーズなサインイン体験（ただしセキュリティキー運用では「パスキーでサインイン」ボタンの方が使いやすい）
- 必要な特性チェックボックス：証明書ベース・ハードウェア保護・FIPS準拠などの要件をAuthenticator単位で制御可能に
Google TitanのようなDevice-boundパスキーは、エンタープライズのPhishing-resistant認証要件 にぴったりです。Early Access段階の今のうちに検証しておくと、GA時にスムーズに展開できると思います！
パスキー関連の設計・導入でお困りの方は、ぜひお気軽にご相談ください 💪
