【Okta】パスキー設定ガイド ｰ 管理者が押さえたい設計・設定・運用のポイントを徹底解説

はじめに

こんにちは。ネクストモードのゆきなわです。

パスワードに代わる認証手段としてパスキー (Passkeys) の普及が進んでいます。FIDO Alliance が開始した The Passkey Pledge には Okta を含む多くの企業が参加しており、業界全体でパスワードレス化の取り組みが広がっています。Okta Identity Engine (OIE) でもパスキーによる認証がサポートされており、フィッシング耐性のある認証を実現できます。

しかし、いざ導入しようとすると「管理画面にパスキー設定がないけどどこから設定できる？」「証明書利用者 ID って何？設定した方がいい？」「ポリシーはどう設定すればいい？」「特定のユーザーに特定の同期パスキーのみ利用を許可できる？」といった、さまざまな疑問や課題に直面することも事実です。また、Okta において機能的に重複する Okta FastPass との使い分けも課題になります。

なお、パスキーの導入自体が自社にとって適切かどうか（Okta FastPass やセキュリティキーとの優先度判断を含む）については、以下の記事で整理していますので、本質的な導入判断の部分で迷われている方はぜひお読みください。

本記事では、主に、パスキーを導入すると決めた方、あるいは条件付きで導入を検討している方を対象に、導入前に決めておくべき設計判断、Okta FastPass との使い分け、公式ドキュメントだけではカバーしきれない運用上の注意点も含めて体系的にご紹介します。

※本記事は2026年2月時点の情報に基づいて作成しています。最新情報は公式ドキュメントをご確認ください。

本ガイドの活用方法

本記事は内容が多岐にわたるため、目的に応じて以下のように読み進めていただくと効率的です。

Okta で初めてパスキーを導入する方は、セクション3から順にお読みいただくことで、基礎知識の理解から設計判断、設定手順、運用上の注意点まで一貫して把握できます。すでに基礎知識をお持ちの方は、セクション5（設計判断）またはセクション7（設定手順）から読み始めていただくのがおすすめです。

パスキーの基礎知識と用語整理

パスキーは FIDO2 / WebAuthn 標準に基づく認証方式です。パスワードの代わりに、デバイスに保存された暗号鍵ペア（公開鍵・秘密鍵）を使って認証を行います。従来のパスワード認証がサーバーに秘密情報を送信するのに対し、パスキーではクライアント側で認証を行い、サーバーには署名付きの認証データ (authenticatorData / clientDataJSON / signature など) が送信されます。

3-1. パスキーの主な特徴

• フィッシング耐性: 認証器 (Authenticator) はサーバーのドメイン情報に対して署名を行い、サーバーがその署名を検証します。これにより、正規のドメインと異なるドメイン（偽サイト）では認証が成立しません
• パスワード不要: 生体認証（指紋・顔認証）や PIN で本人確認を行います
• 所有 + ユーザー検証による多要素認証: デバイスの所有（所有要素）と、生体認証または PIN によるユーザー検証を1つの操作で満たせます
• クロスデバイス認証: PC で QR コードを表示し、スマートフォンで読み取って認証する クロスデバイス認証 (Cross-Device Authentication; CDA) が可能です。これにより、PC に生体認証デバイスが内蔵されていなくても、手元のスマートフォンをセキュリティキー代わりにパスキー認証を完了できます。業務用の生体認証付きのスマートフォンを認証デバイスとして活用するユースケースなど、パスキーのポータビリティを最大限に発揮できる機能です

Okta では FIDO2 (WebAuthn) Authenticator としてパスキーがサポートされています。

3-2. パスキーの種類

パスキーには同期パスキーとデバイス固定パスキーの2種類があります。Okta では同期パスキーのブロックが可能であり、後続の同期パスキーを許可するか・ブロックするかの運用設計の判断が必要となります。

両者の違いは、次の設計項目に影響します。

• セキュリティ要件（同期を許容するか、デバイス固定を必須にするか）
• 端末紛失時のリカバリ方針（自己復旧に寄せるか、再登録を前提にするか）
• ヘルプデスク対応の負荷（本人確認、再登録手順、予備キー配布などの運用）

ヒント: どのパスキー基盤（Authenticator とパスキープロバイダーの組み合わせ）を許可するかの設計については、セクション 5-2 で詳しく解説します。

Okta 上のパスキー関連設定用語

Okta では管理画面・サインイン画面における Authenticator 選択の際、「パスキー」という言葉がダイレクトには出てきません。そのため、初期導入時に管理者・ユーザーともに混乱を招くケースがあります。ここでは Okta 上のパスキー関連用語を整理します。

※重要: パスキーの同期不可とハードウェア保護は必ずしも同義ではない点に注意が必要です。 例えば、iPhone の Secure Enclave で保護されたパスキーは、ハードウェア保護の要件を満たしつつも、iCloud キーチェーン経由で別デバイスに同期される場合があります。そのため、ハードウェアによる保護の有無と同期の可否は、それぞれ独立した概念として整理して理解する必要があります。

（参考）Okta におけるパスキーのリブランディングについて

【Okta】企業で Passkey はアリ？ナシ？採用前に整理したい判断ポイントでも触れいていますが、現在、Okta では FIDO2 (WebAuthn) Authenticator が パスキー Passkeys (FIDO2 WebAuthn) へリブランドされる動きが進んでいます。この変更では、管理者向けの設定ページが統合・簡素化されるほか、Authenticator の表示名をカスタマイズできる機能や、サインイン画面 (Sign-In Widget) に専用のパスキーでサインイン (Sign in with a passkey) ボタンが追加されるなどの UX 改善が含まれる予定です。

これにより、現行のセキュリティキーまたは生体認証 Authenticator という表記で分かりにくかったパスキーの選択が、ユーザーにとってより直感的になることが期待されます。今後 GA（一般提供）になった際には、本記事で取り上げた「管理画面にパスキー設定が見当たらない」といった課題も大幅に解消される見通しです。

本機能は2026年2月にプレビューから早期アクセス (Early Access; EA) に変わった段階です。最新の状況は公式ドキュメントをご確認ください。

導入前の設計判断

パスキーの導入に先立ち、以下の設計項目を確定することが重要です。設定後に変更すると大きな手戻りが発生する項目が含まれています。全体の大まかな流れを下図に示します。

5-1. 証明書利用者 ID の決定

証明書利用者 ID (Relying Party ID) とは

証明書利用者 ID (Relying Party ID; RP ID) はパスキーの認証スコープを定義するドメイン識別子です。FIDO2 クレデンシャル（パスキー）は RP ID に紐づいて作成されるため、RP ID を変更すると、新しい RP ID のスコープ外となる既存のパスキーは利用できなくなります。

RP ID は導入前に確定する

Okta のデフォルト設定では Okta org のドメイン（例: yourcompany.okta.com）が使用されますが、カスタムドメイン（例: login.yourcompany.co.jp）にも変更可能です。

デフォルトの okta.com サブドメインを使うと、将来別の IdP 環境に移行する際に全ユーザーの再登録が必要となり、運用負荷が大きくなるケースがあります。FIDO2 の仕様では、パスキーは RP ID（ドメイン）に公開鍵暗号で結び付けられているため、ドメインの変更時は既存クレデンシャルは利用できなくなります。

複数の Okta org URL を使用している場合

組織でカスタムドメインを含む複数の Okta org URL（例: yourcompany.okta.com と login.yourcompany.co.jp と yourcompany-sub.okta.com）を使い分けている場合、FIDO2 (WebAuthn) Authenticator は追加した org URL からのみアクセスできます。複数の org URL でパスキーを利用するには、それぞれの org URL ごとに FIDO2 Authenticator を追加する必要があります。

5-2. パスキーの利用を許可する Authenticator・プロバイダーの選定

パスキーを導入する際は、どのパスキー基盤（Authenticator とパスキープロバイダーの組み合わせ）を許可するかを検討する必要があります。

パスキーの利用には、認証処理（鍵ペアの生成・署名・ユーザー検証）を行う Authenticator（認証器） と、パスキーの保管・同期を担うパスキープロバイダー（クレデンシャルマネージャー） が関わります。多くの場合、この2つは一体で提供されます。

パスキー基盤の種類と特徴

以下の表に、主要なパスキー基盤とその特徴をまとめます。

※1 Windows Hello は原則としてデバイス (TPM) に鍵を固定しますが、個人用 Microsoft アカウントなど設定によっては同期機能を利用できる場合があります。企業利用 (Windows Hello for Business) では一般的にデバイス固定となります。

※2 サードパーティのパスキープロバイダーは、OS のクレデンシャルプロバイダー API を通じてプラットフォーム Authenticator のユーザー検証を利用しつつ、鍵の保管・同期を独自に行います。

他のパスキー基盤では Authenticator とプロバイダーが一体ですが、サードパーティプロバイダーでは両者が分離しており、OS に依存しないマルチプラットフォームでのパスキー同期が可能になります。利用には OS 側のクレデンシャルプロバイダー API 対応が前提となります（iOS 17 以降、Android 14 以降、macOS Sonoma 以降など）。

Okta における制御方法

どのパスキー基盤を許可するかは、Okta 上では主に以下の 2 つの方法で制御します。

同期パスキーのブロックを有効にすると、iCloud キーチェーン、Keeper を含む同期パスキー全般がブロック対象になります。特定の同期パスキープロバイダーのみを許可したい場合は、「同期パスキーのブロック」は使用せず、Authenticator グループで許可する Authenticator Attestation Global Unique Identifier (AAGUID) を明示的に指定するホワイトリスト方式を採用してください。

選定時の検討ポイント

例えば、以下のような方針が考えられます。

• 社内端末ではプラットフォーム Authenticator (Windows Hello / Touch ID) を許可し、特権アクセスには YubiKey を必須にする
• マルチ OS 環境のユーザーには Keeper をパスキープロバイダーとして指定し、Authenticator グループで Keeper と社内指定のデバイスのみを許可する
• BYOD ユーザーにはプラットフォーム Authenticator のみ許可し、ローミング Authenticator は社内配布のセキュリティキーに限定する

どのパスキー基盤を許可するかの制御は、Okta の Authenticator グループ機能で実現できます。具体的な設定手順はセクション 7-3 を参照してください。

5-3. 同期パスキーを許可するかブロックするか

パスキー導入における重要な設計判断の一つが、同期パスキーを許可するかどうかです。

比較表

ブロック時の注意点

設定オプション「同期可能なパスキーをブロック (Block synced passkeys)」は、Authenticator の電子署名を検証してブロックする方式 (Attestation) ではありません。Okta は同期パスキーを作成することが既知である Authenticator を識別し、ブロックする方式を採用しています（公式ドキュメントでは “blocks authenticators that are known to create syncable passkeys” と説明されています）。そのため、以下のようなケースが発生する可能性があります。

• 新しいプロバイダーが登場した場合、Okta のブロックリストが更新されるまでは通過する
• 一部のデバイス固定とされる Authenticator が実際は同期可能

より厳密な制御（特定の同期プロバイダーのみ許可する等）が必要な場合は、セクション 5-2 で解説した Authenticator グループによる AAGUID ベースのホワイトリスト管理や、証明書ベースの attestation 検証（認証検証、主にセキュリティキーで有効）の併用を検討してください。

5-4. 紛失時などのリカバリ対応の設計

パスキー導入時に見落とされがちですが、ユーザーがデバイスを紛失した場合のリカバリフローは事前に設計しておく必要があります。この点は FIDO Alliance でも継続的に議論されている課題です。

リカバリ戦略のオプション

（重要）管理者リセットをリカバリの主要手段にする場合、「リセット依頼時にどう本人確認を行うか」に関するプロセスを必ず整備してください。

パスキーと Okta FastPass の使い分け

Okta Identity Engine には、フィッシング耐性のある認証方式として FIDO2 (WebAuthn) によるパスキー/セキュリティキーと Okta FastPass (Okta Verify) の 2 つの選択肢があります。どちらもフィッシング耐性を持つ点は共通ですが、それぞれが適するユースケースは異なります。

使い分けの原則

基本的には、社内管理デバイス（MDM / UEM 配下）なら Okta FastPass、BYOD・社外ユーザーならパスキーとなります。ただし、それぞれは排他的な認証方式ではないため、併用することでより Okta の強みを引き出すことができます。以下で詳しく見ていきます。

6-1. 機能比較表

※ 利用には Adaptive MFA ライセンスの契約が必要です。

6-2. それぞれの強みと活用ポイント

パスキーが適しているケース

• BYOD やアプリのインストールが制限される環境: ブラウザの標準機能で動作するため、Okta Verify をインストールできない端末でもフィッシング耐性のある認証を実現できます
• 外部の協力会社・パートナー・顧客への展開: 自社の MDM 管理下にないデバイスを使うユーザーにも、追加アプリなしで導入可能です
• ChromeOS / Linux 環境: Okta FastPass が非対応のプラットフォームでは、FIDO2 (WebAuthn)（パスキー/セキュリティキー）が実質唯一のフィッシング耐性オプションです
• 業務用スマートフォンの活用: 社員に支給している業務用スマートフォン端末を、PC ログイン用のセキュリティキーとして活用できます (CDA)。専用の物理キーを購入・管理するコストを削減できます。
• FIDO 標準への準拠が求められる場合: 業界標準に準拠した認証方式を採用したい場合に適しています
• セキュリティキー（YubiKey 等）を活用する運用: 物理キーをベースとした運用を想定している場合は FIDO2 が必須です

Okta FastPass が適しているケース

• デバイスの管理・検証が必要な環境: MDM と連携し、デバイスが管理対象状態かどうかを認証条件として評価できます。パスキーにはこの機能がありません
• デバイスのセキュリティ状態に基づくアクセス制御（デバイスポスチャー重視）: デバイス保証ポリシーにより、OS バージョン、セキュリティパッチの適用状況、スクリーンロックの有無などを認証時にチェック可能です。デバイスが安全でなければアクセスさせないというゼロトラスト原則に基づく制御はパスキーだけでは実現できません
• ユーザー体験を最大限スムーズにしたい場合: サイレント認証（ユーザーが意識せずバックグラウンドで認証完了）が可能です
• 社内デバイスの統制が取れている環境: 全従業員に Okta Verify をインストールさせる運用が可能であれば、デバイスシグナル活用によるゼロトラスト的なアクセス制御を実現できます

6-3. 併用によるメリット

実際の運用では、パスキーと Okta FastPass は必ずしも排他的ではなく、併用することでカバー範囲を強化することもできます。

認証ポリシー側では、所有要素の制約でフィッシング耐性を指定すれば、FIDO2 (WebAuthn) と Okta FastPass のどちらでも条件を満たせます。このようにユーザーの環境に応じて柔軟に使い分けられるのが併用の最大のメリットです。

補足: Okta FastPass は FIDO 標準とは互換性がありません。 

そのため、FIDO 標準への準拠が組織の情報セキュリティ要件にある場合は、パスキー/セキュリティキーの利用が唯一の選択肢となります。

管理者設定ガイド

ここからは、パスキーを有効にするための設定手順を順を追ってご紹介します。

7-1. FIDO2 (WebAuthn) Authenticator の追加

まず、FIDO2 (WebAuthn) Authenticator を Okta に追加します。

1. Okta Admin Console で [セキュリティ] > [Authenticator] に移動します
2. [設定] タブで [Authenticator を追加] をクリックします 
   
3. FIDO2（WebAuthn） カードの [追加] をクリックします
4. FIDO2 (WebAuthn) の設定画面に遷移するので、必要に応じて以下のオプション設定を行います
   1. （任意）一般設定で証明書利用者 (RP ID) をカスタマイズします
      1. 証明書利用者 ID の入力欄に事前に決定したドメインを入力します（セクション 5-1 参照）
      2. [ドメインを確認する] ボタンをクリックします
      3. 検証完了後、トグルボタンをクリックし設定を有効化します
   2. 認証設定パスキーおよび追加保証でそれぞれパスキー自動入力（任意）とユーザー検証を設定します（それぞれの詳細はセクション 7-2「パスキー固有の設定オプション」で後述します）
5. [追加] をクリックして保存します

7-2. パスキー固有の設定オプション

Authenticator 追加時、または Authenticator 一覧で FIDO2 (WebAuthn) の [アクション] > [編集] から、パスキー固有のオプション設定を行うことが可能です。

設定オプションのリリース状況について: 組織やリリース時期によって、機能の表示有無は org ごとに異なります。2026年2月現在、パスキー自動入力 (Passkeys Autofill) と同期パスキーのブロック (Block synced passkeys) は早期アクセス (Early Access; EA) 機能として提供されているため、Admin Console の [設定] > [機能] でステータスを確認し、必要に応じて有効化してください。

パスキー自動入力

ON にすると、ユーザーがサインイン画面のユーザー名フィールドをクリックした際に、登録済みのパスキー候補がブラウザの自動入力として表示する UI が有効化されます。

※パスワードファーストのフロー（最初にパスワード入力を求める認証ポリシー）ではパスキー自動入力は動作しません。また、セキュリティキーは候補に表示されません。

ユーザー検証の設定

この設定は、主に FIDO2 (WebAuthn) Authenticator の登録時 にユーザー検証 (User Verification) をどう要求するかを定義します。実際の体験はプラットフォーム差があり、OS によっては PIN のセットアップを求められる場合があります。

多くのケースでは 推奨がバランスの取れた選択肢です。必須は古いセキュリティキーなど一部のデバイスで登録失敗の原因になる可能性があるため、対象とするデバイスを事前に確認してください。

注意: ブラウザや Authenticator の組み合わせによっては、この設定が期待通りに適用されないケースがあります（例: 一部のブラウザが Required の指定を無視する等）。導入前にテスト環境で対象ブラウザ・デバイスでの挙動を検証してください。

同期パスキーのブロック

有効化すると、iCloud キーチェーン、Google パスワードマネージャー、Keeper 等のサードパーティプロバイダーを含む、同期パスキーの新規登録が一括でブロックされます。既存登録を即時に無効化する機能ではありません。設計判断のセクション 5-3 で検討した方針に基づいて設定してください。本オプションは2026年2月現在、早期アクセスでの提供となりますが、設定は Admin Console の [設定] > [機能] からの有効化・無効化となります（下図）。

特定の同期プロバイダーのみ許可したい場合（例: Keeper は許可し、他の同期プロバイダーはブロック）は、この設定ではなく Authenticator グループによる AAGUID ベースの制御を使用します。詳しくはセクション 5-2「Okta における制御方法」、7-3「利用可能なパスキー基盤の制限」を参照してください。

本設定にはいくつかの制約事項があります。

• Chrome on macOS で作成されるパスキーはデバイス固定として扱われるため、ブロック対象外です
• iOS 16 の端末では、同期パスキーをブロックすると FIDO2 (WebAuthn) Authenticator 自体が利用できなくなります。代替として Okta FastPass、または NFC / USB-C 対応セキュリティキーを有効にしてください
• macOS Monterey の Safari では、同期パスキーをブロックすると Touch ID による登録ができなくなります

7-3. 利用可能なパスキー基盤の制限

組織のセキュリティポリシーに応じて、利用可能な FIDO2 (WebAuthn) Authenticator（パスキー基盤）を特定のデバイス・メーカーに限定できます。これは AAGUID (Authenticator Attestation Global Unique Identifier) と Authenticator グループを組み合わせて実現します。

実現できること

Authenticator グループを作成し、Authenticator 登録ポリシーで指定することで、特定の Authenticator のみ登録・利用を許可する制御が可能になります。例えば以下のような運用を実現できます。

• YubiKey 5 シリーズのみ許可
• Keeper のみ許可し、他の同期プロバイダーはブロック
• Windows Hello と社内指定のセキュリティキーのみ許可

セキュリティキーの制限だけでなく、パスキー基盤（プラットフォーム Authenticator やサードパーティプロバイダー）の制限にも活用できる点がポイントです。

設定の流れ

例として「Keeper と YubiKey 5 シリーズのみ許可し、それ以外はブロックする」場合の流れを示します。

1. 許可する Authenticator の AAGUID を特定する
2. FIDO MDS AAGUID リストに掲載されていない Authenticator（例: Keeper）は、カスタム AAGUID として登録する
3. 上記を含む Authenticator グループを作成する
4. Authenticator 登録ポリシーで当該グループのみを許可する（セクション 7-4 で設定）

これにより、FIDO MDS AAGUID リストに掲載されていないプラットフォーム Authenticator やサードパーティプロバイダーも含めて、組織が承認した Authenticator だけにパスキー利用を限定できます。

ヒント: プラットフォーム Authenticator やサードパーティプロバイダーの AAGUID は、コミュニティが管理している Passkey Authenticator AAGUIDs Explorer で確認できます。

本サイトでは iCloud キーチェーン (Apple Passwords)、Google パスワードマネージャー、Windows Hello、Keeper、1Password など主要なパスキー基盤の AAGUID の一覧を提供しています。セキュリティキーの AAGUID については、Okta の FIDO MDS AAGUID リストまたは FIDO Alliance Metadata Service (MDS) を参照してください。

注意: Authenticator グループを使用している場合、FIDO U2F (Universal 2nd Factor) によるセキュリティキーの登録はサポートされません。

Authenticator グループの作成

FIDO MDS AAGUID リストおよびカスタム AAGUID から、許可する Authenticator のグループを作成します。

設定手順:

1. [セキュリティ] > [Authenticator] に移動します
2. FIDO2 (WebAuthn) の [アクション] のボタンメニューから [Authenticator グループ] を開きます
3. [グループを追加] をクリックします
4. グループ名を入力し、許可する Authenticator を AAGUID リストから選択して追加します（下図例: YubiKey 5 シリーズを含む Authenticator グループの作成）。後述するカスタム AAGUID の指定も可能です。
   1. Authenticator グループ名を入力します
   2. このグループのAAGUID Authenticator に登録する Authenticator をリストから検索・選択することで設定します（複数設定可）
   3. [グループを追加] をクリックします
5. （任意）設定が必要なグループについて3, 4 を繰り返します

追加した Authenticator グループは以下のように一覧に表示されます（下図は2つの Authenticator グループを追加した場合の例）。

作成した Authenticator グループは、Authenticator 登録ポリシーで指定します（セクション 7-4 で後述）。

カスタム AAGUID の設定

FIDO MDS AAGUID リストに掲載されていない Authenticator（Windows Hello 等のプラットフォーム Authenticator、Keeper 等のサードパーティプロバイダーなどのパスキー基盤）を Authenticator グループに追加するには、カスタム AAGUID を登録します。

設定手順:

1. FIDO2 (WebAuthn) の [アクション] のボタンメニューから [AAGUID リスト] を開きます
2. [カスタム AAGUID を追加] をクリックします
3. カスタム AAGUID を設定します
   1. 名前（Authenticator 名）を入力します（図: Keeper の例）
   2. AAGUID を入力します（図: Keeper の例）
   3. （任意）認証検証の証明書を使用して認証を有効化します。Attestation 検証（認証検証）用の証明書をアップロードします。必要に応じて Authenticator の特性（ハードウェア保護、FIPS 準拠、ローミングなど）を選択します
   4. [保存] をクリックします
4. 設定が必要な Authenticator について2, 3 を繰り返します

追加したカスタム AAGUID は以下のように一覧に表示されます（下図は3エントリを追加した場合の例）。

※カスタムエントリは FIDO MDS のエントリと AAGUID が重複した場合、カスタム側が優先されます。セキュリティキーの取得や環境へのデプロイを行う前に、Okta で利用可能な Authenticator を AAGUID リストで確認しておくことを推奨します。

7-4. Authenticator 登録ポリシーの設定

Authenticator を追加しただけでは、ユーザーはまだパスキーを登録できません。Authenticator 登録ポリシーにパスキーを追加する必要があります。

1. [セキュリティ] > [Authenticator] を開き [登録] タブに移動します
2. 既存のポリシーで [アクション] > [編集] を開くか（下図1）、[ポリシーを追加] をクリックします（下図2）
3. （任意）ポリシーを割り当てるグループを指定します
4. FIDO2 (WebAuthn) のセクションに移動し、設定を行います
   1. 必須または任意を指定します

      設定	挙動
      必須（Required）	ユーザーに登録を強制します。次回サインイン時に登録プロンプトが表示されます
      任意（Optional）	ユーザーが任意で登録できます。強制はしません
      無効（Disabled）	ユーザーはパスキーを登録できません

   2. 任意の WebAuthn Authenticator または選択したグループリストからの Authenticator を選択します。後者を選択した場合は、作成済みの Authenticator グループを選択して設定します（図は Authenticator グループ「同期パスキー」「YubiKey 5 Series」を選択する場合の例）
   3. [ポリシーを更新]（新規ポリシーの場合は [ポリシーを追加]）をクリックします

段階的にロールアウトする場合は、例えば、まず特定のグループ（IT 部門など）のみに必須を適用して試験運用し、その後、全社グループに任意で展開、最終的に 必須に切り替えるのが安全です。

7-5. 認証ポリシー (Authentication Policy) の設定

アプリケーションへのサインイン時にパスキーを利用できるようにするため、認証ポリシーを設定します。

1. [セキュリティ] > [認証ポリシー] に移動し、[アプリのサインイン] を開きます
2. 対象のポリシー (例: Okta Dashboard) を選択し、ルールを編集します
3. 以下を設定します

   設定項目	設定値	説明
   認証方式	任意の2要素タイプ	2要素認証を要求します
   所有要素の制約	・フィッシング耐性 ・ユーザーインタラクションを必須とする ・（オプション）ハードウェア保護	・FIDO2 (WebAuthn) / Okta FastPass が条件を満たします ・ユーザーインタラクションを必須にするとパスキーのみで任意の2要素タイプの条件を満たすことができます（詳細はセクション10 Q3 を参照してください）

フィッシング耐性を要求すると、FIDO2 (WebAuthn) または Okta FastPass でしかサインインできなくなります。FIDO2 (WebAuthn) にはパスキーだけでなくセキュリティキーによる認証も含まれます。パスキー未登録のユーザーがロックアウトされないよう、登録ポリシーと合わせて検討してください。

ユーザー体験: 登録から認証までのフロー

ここでは、エンドユーザーがパスキーを登録・認証する際の実際の操作フローを説明します。

利用環境

8-1. パスキーの登録

ユーザーがパスキーを登録する方法は2つあります。

パターン1: サインイン時に登録

Authenticator 登録ポリシーで必須または任意に設定している場合、設定後の初回ユーザーのサインイン時に登録プロンプトが表示されます。

1. アプリケーションにアクセスし、Okta のサインイン画面でユーザー名、パスワードを入力を進めます
2. セキュリティ方式の登録を促すプロンプトが表示されます。パスキーの設定のために、セキュリティキーまたは生体認証 Authenticator の [セットアップ] をクリックします
3. さらに [セットアップ] をクリックします
   
4. ブラウザ / OS のデフォルトのパスキー作成ダイアログが表示されます（Google パスワードマネージャーの例）。
   
   1. （任意）iCloud キーチェーンなど、他のパスキー基盤でパスキーを登録する場合は別の方法で保存をクリックします
   2. （1 で別の方法で保存をクリックした場合）パスキーを保存する場所を選択します。例えば、後述のクロスデバイス認証 (CDA) を利用する場合は、スマートフォン、タブレット、またはセキュリティキーを選択します（※利用環境によって表示されるパスキー基盤は異なります）
      パスキー作成のダイアログが表示されます（下図はiCloud キーチェーンを選択した場合）
      
5. 生体認証（指紋・顔認証など）または PIN で本人確認を行います
6. 登録およびサインインが完了となり、アプリケーション画面に遷移します

パターン2: Okta ダッシュボードから登録

1. Okta End-User Dashboard（Okta ダッシュボード）にサインインします
2. 右上のユーザー名横の矢印をクリック → [設定] を選択します
3. 本人確認を求められるので、登録済みの認証方法で認証します
4. [セキュリティ方式] セクションで FIDO2 (WebAuthn) の [セットアップ]（すでに登録済みのものがある場合は [他のセットアップ]）をクリックします
5. ブラウザのパスキー作成ダイアログに従い登録します（前述のパターン1と同様の方法のため詳細は省略）

※ ユーザーあたり最大10個 の FIDO2 Authenticator （パスキーおよびセキュリティキー）を登録できます。リカバリに備えて、複数デバイス・複数ブラウザでの事前登録をユーザーに推奨してください。

8-2. パスキーによる認証

登録が完了すると、ユーザーは以下の方法でサインインできます。

ユーザー名を入力するフロー

1. サインイン画面でユーザー名を入力（下図1）して [次へ]（下図2）をクリックします
2. 登録済みのパスキーでの本人確認が求められます。生体認証 / PIN で本人確認を行います
   
3. 本人確認に成功するとサインイン完了です

パスキー自動入力を有効化している場合

設定でパスキー自動入力オプションを有効化している場合（セクション 7-2 参照）、ユーザー名の入力を省略できます。

1. サインイン画面でユーザー名フィールドをクリックします。登録済みユーザー名とパスキーの候補が表示されるので、該当するパスキーをクリックします
2. 登録済みのパスキーでの本人確認が求められます。生体認証 / PIN で本人確認を行います（画像は前述のユーザー名を入力するフローと同様のため省略）
3. 本人確認に成功するとサインイン完了です

クロスデバイス認証 (CDA) を使う場合

この方法を使えば、PC に生体認証デバイスが内蔵されていない場合でも、手元のスマートフォンでパスキー認証を完了できます。

1. PC のサインイン画面でユーザー名入力して [次へ] をクリックします
2. パスキー選択ダイアログでスマートフォン、タブレット、またはセキュリティキーを選択します
   ※PC にパスキーが格納されていない場合はこのステップがスキップされ、ステップ3の QR コードが表示されます。また、以下の画面が表示されず、デフォルトのパスキーでの本人確認が求められている場合は、キャンセルをクリックしてください
   
3. QR コードが表示されます
   
4. スマートフォン (iPhone / Android) のカメラで QR コードを読み取ります
   ※PC とスマートフォン双方の Bluetooth が ON になっている必要があります
5. スマートフォンでパスキーを使用をタップしスマートフォン側で生体認証 / PIN で本人確認を行い、本人確認に成功するとサインイン完了です（スマートフォンの機種、OSバージョンなどによって表示が異なります）
   

8-3. パスキーの登録・認証が制限されている時の挙動

利用可能なパスキー基盤の制限を実施している場合（設定方法はセクション 7-2、7-3 を参照）は、パスキーの登録時およびパスキーでの認証時に以下のエラーが表示され、登録・認証がブロックされます。

運用上の注意点

実際にパスキーを運用してみると、公式ドキュメントだけでは分かりにくい落とし穴がいくつかあります。ここでは、管理者が事前に把握しておくべきポイントをまとめました。

9-1. ブラウザ別の挙動の違い

ブラウザや OS によってパスキーの挙動が異なる場合があります。事前に把握しておくと、円滑にトラブルシューティングができます。

※ プラットフォーム Authenticator は、端末内蔵の Authenticator（Windows Hello、Touch ID、Face ID など）を指します。詳しくは下記公式ドキュメントを参照してください。

9-2. その他の注意事項

• 2022 年 11 月 30 日以前に登録されたセキュリティキー は再登録が必要です
• Chrome を最新化 していない端末では、FIDO2 (WebAuthn) が利用できない場合があります
• MFA Credential Provider for Windows ではパスキーは非サポートです
• ユーザー検証が「非推奨」で PIN 有効のセキュリティキー を Chrome で使用すると、登録が失敗します
• 事前登録済みのセキュリティキーを解除する運用は避け、必要時は Okta End-User Dashboard での再登録手順を案内してください

よくある質問 (FAQ)

Q1. 1 人のユーザーが複数の FIDO2 Authenticator（パスキーやセキュリティキー）を登録できますか？

可能です。 Okta の FIDO2 (WebAuthn) Authenticator は、パスキーとセキュリティキーの両方をカバーしています。ユーザーは最大 10 個まで登録でき、パスキーとセキュリティキーを混在させることも可能です。

Q2. パスキーを登録した端末を紛失した場合はどうなりますか？

同期パスキーの場合: 別のデバイスで同じクラウドアカウント（iCloud、Google アカウント、Keeper アカウント等）にサインインすれば、パスキーは自動的に同期されます。

デバイスバウンドパスキーの場合: 紛失したデバイスに紐づくパスキーは使用不能になります。以下の順で対処します。

1. 別デバイスで事前登録したパスキーがある場合 → そちらでサインイン
2. バックアップ Authenticator（Okta Verify 等）がある場合 → そちらでサインインし、新デバイスでパスキーを再登録
3. 上記がいずれもない場合 → 管理者が Admin Console からユーザーの FIDO2 登録をリセットし、再登録を行う

重要: リカバリの事前設計については、本記事のセクション 5-4 を参照してください。FIDO2 の登録は単一のブラウザ・デバイスだけに依存するとロックアウトのリスクがあるため、複数ブラウザ・複数デバイスでの事前登録を推奨します。

Q3. パスワードを完全に廃止してパスキーのみにできますか？

条件付きで可能です。 Okta OIE ではパスワードレスサインインがサポートされています。

実現するには以下の条件をすべて満たす必要があります。

1. 認証ポリシーで認証方式を任意の2要素タイプに設定し、パスワードを要素として要求しない構成にします
2. FIDO2 (WebAuthn) Authenticator のユーザー検証を必須に設定します
3. 対象端末で生体認証（指紋・顔認証）を有効化 しておきます
4. 必要に応じて、認証ポリシーのルールでデバイスパスコードまたは生体認証によるユーザー検証を必須とするを有効にします

これにより、パスキーが 所有要素 (Possession) と 生体要素 (Biometric) を同時に提供し、パスキー単独で2要素認証の要件を満たせます。ただし、全ユーザーのパスキー登録が完了し、リカバリフローが整備されていることが前提となるため、段階的に移行することを推奨します。

注意: パスキーは、所持要素に加えてユーザー検証 (PIN または生体認証) を伴う強力な認証手段です。一般的な FIDO2 / WebAuthn 規格では、PIN と生体認証はともにユーザー検証として同等に扱われます。しかし、Okta のパスワードレス設定においては、所有要素と生体認証要素の両方を満たすことが求められます。

Q4. 既存の MFA (OTP 等) からパスキーへの移行はどう進めるべきですか？

一般的な移行アプローチは以下の通りです。

1. パスキーを任意として Authenticator ポリシーに追加し、既存の MFA と並行運用します
2. ユーザーへの利用周知を行います
3. 登録率が一定の閾値を超えたら必須に切り替えます
4. 認証ポリシーでフィッシング耐性を段階的に要求していきます

具体的な移行の流れの例を下図にまとめました。

Q5. Attestation 検証（認証検証）は有効にすべきですか？

組織のセキュリティ要件次第となります。

• 有効にするメリット: 登録時に電子署名により Authenticator の真正性を検証でき、未承認デバイスの使用を防止できます
• 有効にするデメリット: 一部の Authenticator（特にプラットフォーム Authenticator）は attestation をサポートしていないため、登録できなくなる可能性があります

より高いセキュリティが求められる場合に有効な設定ですが、まずは検証環境で動作を確認してから、本番環境へ展開することをお勧めします。

まとめ

Okta でのパスキー導入は、Authenticator の追加設定自体はシンプルですが、導入前の設計判断、ポリシー設計、運用時の例外対応まで含めて整理しておくと、展開後の手戻りを減らしやすくなります。

特に押さえておきたいポイントは次の4点です。

1. RP ID は早い段階で方針を確定する 既定ドメインでも導入は可能ですが、将来のドメイン運用や IdP 構成変更の可能性がある場合は、カスタムドメインの採用も含めて事前に検討しておくと運用が安定します。なお、RP ID を変更すると、スコープ外となる既存登録は引き継げないため、再登録対応が必要になります。
2. 同期パスキーの許可/ブロックは要件ベースで決める 利便性を優先するか、管理・統制を優先するかで最適解は変わります。セキュリティ要件、ヘルプデスク負荷、端末構成（管理端末 / BYOD の比率）を合わせて判断してください。
3. パスキーと Okta FastPass は併用を前提に設計する 例えば管理端末では FastPass、BYOD や外部ユーザーにはパスキーといった形で対象に応じて使い分けると、ユーザー体験と統制のバランスを取りやすくなります。
4. リカバリフローを先に設計する 複数デバイス登録の推奨、バックアップ Authenticator の併用、本人確認を伴うリセット手順を事前に整備しておくことで、ロックアウト時のヘルプデスク対応が速やかに実施できます。

まずは小規模なグループでのパイロット運用から開始し、段階的に全社展開を進めていくアプローチが最も確実です。

本記事が、皆様の Okta 運用におけるパスキー導入検討の一助となれば幸いです。

参考リンク

• FIDO2（WebAuthn）Authenticator を構成する | Okta Identity Engine
• FIDO2（WebAuthn）のサポートと動作 | Okta Identity Engine
• FIDO2（WebAuthn）Authenticator とフィッシング耐性のあるポリシーをセットアップする | Okta Identity Engine
• フィッシング耐性のある Authenticator 登録 | Okta Identity Engine
• パスワードレスユーザーに MFA を構成する | Okta Identity Engine
• フィッシング耐性のある認証 | Okta Identity Engine
• パスキー入門 | Okta
• パスキーによるフィッシング耐性の向上 | Okta
• Passkeys | Fido Alliance

Okta についてのお問い合わせ

Okta の導入に関心をお持ちの方、本記事では紹介できていない、詳細なライセンス体系や価格などをお知りになりたい方は、ぜひ弊社窓口までお問い合わせください。