ログイン画面で「パスキーを作成しますか？」という案内を見かける機会が増えました。パスワードの使い回しやフィッシング詐欺への不安から、パスワードに頼らないログイン方式としてパスキーが急速に広がっています。とはいえ「結局パスキーとは何で、どういうしくみでパスワードより安全なのか」を自分の言葉で説明できる方は、まだ多くないかもしれません。
パスキーを理解する近道は、ログインのときに端末とサービスの間で何がやりとりされているのか、その裏側の流れを順に追うことです。公開鍵暗号という技術がどこで効いているのかが見えると、安全性の理由まで一本の線でつながります。
本記事では、パスキーの仕組みを登録とログインの流れに沿って解説します。公開鍵暗号による安全性の理由、パスワードとの違い、生体認証やFIDO2・WebAuthnとの関係、同期パスキーとデバイス固定パスキーの違いまで整理し、自社サービスにパスキーを取り入れたい開発・プロダクト部門に向けて実装の選択肢もご紹介します。
目次
パスキーとは？まず一言でわかる定義
パスキー（passkey）とは、FIDO（ファイド）という業界標準にもとづく、公開鍵暗号を使ったパスワードレス認証の資格情報です。スマートフォンやパソコンに保存され、パスワードの代わりに鍵のペアでログインを行います。FIDOアライアンスはパスキーを「FIDO標準にもとづく認証資格情報で、パスワードを暗号鍵のペアに置き換えるもの」と説明しています。
ここでいう「鍵のペア」とは、サービス側に預ける公開鍵と、自分の端末だけが持つ秘密鍵の組み合わせです。パスワードのように「本人とサービスが同じ秘密の文字列を共有する」方式ではないため、仕組みそのものがフィッシングや漏洩に強いという特徴があります。この理由は後半の仕組みの解説で順に見ていきます。
パスキーを支える技術は「FIDO2」と呼ばれる標準です（FIDOという認証規格の最新世代にあたります）。FIDO2は、Webブラウザとサービスの間の規格であるWebAuthn（ウェブオースン）と、端末内の認証器とブラウザの間の規格であるCTAPの2つで構成されます。用語の関係は後半で改めて整理します。
出典・参考資料（1件）
- 出典：Passkeys（Passwordless Authentication）｜FIDO Alliance（https://fidoalliance.org/passkeys/）
パスキーの仕組み：登録とログインで裏側は何が起きているのか
ここからは、パスキーを使うときに端末とサービスの間で何がやりとりされ、何が保存・照合されるのかを見ていきます。まず登録とログインの流れを順に追い、それを支える公開鍵暗号・生体認証の役割・フィッシングに強い理由まで解説します。
パスキーを登録する（鍵ペアを作る）流れ
パスキーの登録は、サービスに初めてパスキーを設定するときに行われます。おおまかな流れは次のとおりです。
- 利用者がサービスで「パスキーを作成する」操作を行います。
- 端末（認証器）が、そのサービス専用の公開鍵と秘密鍵のペアを新しく生成します。
- 生体認証やPINで「端末の持ち主本人である」ことを確認します。
- 公開鍵だけがサービスに送られ、利用者のアカウントに結びつけて保存されます。
- 秘密鍵は端末内に安全に保持され、サービス側には渡りません。
重要なのは、サービスに渡るのは公開鍵だけで、秘密鍵は端末から出ていかない点です。しかも鍵のペアは登録したサービスごとに別々に作られるため、あるサービスの情報が漏れても、ほかのサービスのログインには使えません。パスワードの使い回しのような問題が、構造的に起こらないしくみです。
出典・参考資料（2件）
- 出典：How passkeys work｜Passkey Central（FIDO Alliance）（https://www.passkeycentral.org/introduction-to-passkeys/how-passkeys-work）
- 出典：Web Authentication: An API for accessing Public Key Credentials – Level 2｜W3C Recommendation（8 April 2021）（https://www.w3.org/TR/webauthn-2/）
パスキーでログインする（認証）流れ
2回目以降のログインでは、登録済みの鍵ペアを使って本人確認を行います。流れは次のとおりです。
- 利用者がログインしようとすると、サービスが「チャレンジ」と呼ばれるランダムな値を端末に送ります。
- 利用者が生体認証やPINで本人確認を行い、端末内の秘密鍵が使える状態になります。
- 端末が、そのチャレンジに秘密鍵でデジタル署名を行います。
- 署名がサービスに返され、サービスは保存してある公開鍵でその署名を検証します。
- 署名が正しければ、秘密鍵を持つ本人からのアクセスだと確認でき、ログインが成立します。
この「チャレンジに秘密鍵で署名し、公開鍵で検証する」方式をチャレンジレスポンス認証と呼びます。毎回異なるチャレンジに署名するため、通信を盗み見られても、盗んだ署名を後から使い回す攻撃（リプレイ攻撃）は成立しません。パスワードのように「正解の文字列」そのものが流れることがない点が、ログインの安全性を支えています。
出典・参考資料（1件）
- 出典：How passkeys work｜Passkey Central（FIDO Alliance）（https://www.passkeycentral.org/introduction-to-passkeys/how-passkeys-work）
これを支える公開鍵暗号のしくみ（秘密鍵は端末から出ない）
登録とログインの両方で鍵になっているのが、公開鍵暗号という方式です。ペアになった2つの鍵のうち、公開鍵は誰に見られても構わない鍵、秘密鍵は本人だけが持つ鍵という役割の違いがあります。パスキーはこの鍵ペアを、データを暗号化して送るためではなく、秘密鍵で署名し公開鍵で検証する電子署名のために使います。
秘密鍵で作った署名は、ペアの公開鍵でしか正しく検証できません。この性質により、サービスは公開鍵を持っているだけで「署名したのは秘密鍵を持つ本人だ」と確認できます。サービス側が保存するのは公開鍵だけなので、万一サービスのデータが漏れても、その情報だけでは本人になりすましてログインすることはできません。
秘密鍵は、端末に備わるセキュリティ専用の保護領域（iPhoneのSecure Enclaveなど）に保管され、生体認証やPINを通さなければ取り出して使えないように守られます。ログインのたびにネットワークへ送信されることもありません（複数端末で使う同期パスキーの扱いは後述します）。
鍵と鍵穴にたとえるなら、サービスが持つのは「公開鍵という鍵穴」で、本人だけが「秘密鍵という鍵」を手元に持ち続けるイメージです。
生体認証・PINはどこで効いているのか（生体情報はサーバーに送られない）
パスキーというと指紋認証や顔認証を思い浮かべる方が多いのですが、生体認証そのものがパスキーなのではありません。生体認証やPINは、端末内の秘密鍵を使うための「持ち主本人である」ことの確認（ユーザー検証）として働きます。
顔や指紋といった生体情報は端末内で照合され、サービス側（サーバー）に送られることはありません。サービスに届くのは、あくまで秘密鍵で作られた署名だけです。「生体情報がサービスに登録・送信されるのでは」という不安は、仕組みの上では当たりません。
出典・参考資料（1件）
- 出典：How passkeys work｜Passkey Central（FIDO Alliance）（https://www.passkeycentral.org/introduction-to-passkeys/how-passkeys-work）
なぜフィッシングに強いのか（パスキーはドメインに紐づく）
パスキーがフィッシングに強い最大の理由は、鍵のペアが登録したサービスのドメイン（オリジン）に紐づいている点にあります。WebAuthnの仕様では、認証のたびに要求元のオリジンが署名の対象に含まれます。
the full origin of the requester is included, and signed over, in the attestation object produced when a new credential is created as well as in all assertions produced by WebAuthn credentials.
Web Authentication: An API for accessing Public Key Credentials – Level 2（§6.3）｜W3C Recommendation（https://www.w3.org/TR/webauthn-2/）
この一文は、認証のたびにアクセス元のドメイン（オリジン）そのものが署名の対象に含まれることを意味します。
この仕組みにより、本物そっくりの偽サイト（例：正規ドメインに似せた別ドメイン）にアクセスしても、ドメインが一致しないためパスキーでの認証は成立しません。パスキーは登録したサイトにしか提示されず、利用者が気づかないうちに攻撃者のサイトで認証情報を入力してしまう、という事態が起こらない設計になっています。
利用者が偽サイトを見分けられなくても、仕組みの側でフィッシングを防げる点が、パスワードとの決定的な違いです。
出典・参考資料（2件）
- 出典：Web Authentication: An API for accessing Public Key Credentials – Level 2（§6.3 / Abstract）｜W3C Recommendation（https://www.w3.org/TR/webauthn-2/）
- 出典：How passkeys work｜Passkey Central（FIDO Alliance）（https://www.passkeycentral.org/introduction-to-passkeys/how-passkeys-work）
パスキーとパスワードは何が違うのか
ここまで見た仕組みを踏まえ、パスキーとパスワードの違いを観点ごとに整理します。両者の根本的な違いは「本人とサービスが同じ秘密を共有するかどうか」にあります。
| 観点 | 認証に使う情報 | サーバーに保存される情報 | 漏洩・流出時の影響 | 使い回しのリスク | フィッシング耐性 | 本人確認の手段 |
|---|---|---|---|---|---|---|
| パスワード | 本人とサービスが共有する秘密の文字列 | パスワード（ハッシュ化して保存） | 流出すると、そのまま悪用・なりすましにつながりうる | 同じパスワードの使い回しで被害が連鎖しやすい | 偽サイトに入力させられると盗まれる | 記憶した文字列の入力 |
| パスキー | 端末内の秘密鍵と、サービスが持つ公開鍵のペア | 公開鍵のみ（漏れても単独ではログインに使えない） | 公開鍵が漏れても秘密鍵がなければログインできない | 鍵ペアはサービスごとに別。使い回しが構造的に起きない | ドメインに紐づくため偽サイトでは認証が成立しない | 生体認証・PIN（端末内で照合、生体情報は送信されない） |
※上記はパスワード認証とパスキー認証の一般的な違いを整理したものです。
パスワードは「本人とサービスが同じ秘密を共有する」方式のため、流出・使い回し・フィッシングといった弱点が構造的に生まれます。警察庁などがまとめた統計でも、摘発された不正アクセスの手口は他人のID・パスワードを悪用する「識別符号窃用型」が大半を占めています。
令和６年における不正アクセス行為の検挙件数について、手口別に内訳を見ると、「識別符号窃用型」が511件と全体の90％以上を占めている。
不正アクセス行為の発生状況及びアクセス制御機能に関する技術の研究開発の状況（令和7年3月公表）｜国家公安委員会・総務大臣・経済産業大臣（https://www.soumu.go.jp/main_content/000997024.pdf）
この統計は摘発された事件の手口の内訳であり、被害が増え続けていることを示すものではありません。ただし、取り締まられた不正アクセスの大半がID・パスワードそのものを狙っている事実は、共有する秘密に依存するパスワードの弱点を裏づけています。パスキーは、この「共有する秘密」をなくすことで弱点に対処する方式だといえます。
出典・参考資料（1件）
- 出典：不正アクセス行為の発生状況及びアクセス制御機能に関する技術の研究開発の状況（令和7年3月公表）｜国家公安委員会・総務大臣・経済産業大臣（https://www.soumu.go.jp/main_content/000997024.pdf）
パスキーと生体認証・FIDO2・WebAuthnの関係を整理する
パスキーの解説では、生体認証・FIDO2・WebAuthnといった言葉が入り混じりがちです。ここで各用語の役割を整理しておきます。
- FIDO2：パスワードに頼らない認証を実現するための標準規格の総称です。WebAuthnとCTAPの2つで構成されます。
- WebAuthn：WebブラウザとサービスがやりとりするためのAPI仕様で、W3Cが勧告として策定しています。公開鍵の登録や署名の検証を担います。
- CTAP：スマートフォンやセキュリティキーなどの認証器と、ブラウザなどのクライアントがやりとりするためのプロトコルです。
- パスキー：これらFIDO2の標準にもとづいて作られる、ログイン用の資格情報（鍵のペア）そのものを指す呼び名です。
- 生体認証・PIN：パスキーを使うときに、端末内で秘密鍵を使ってよいか本人確認するための手段です。パスキーそのものではありません。
整理すると、FIDO2という標準の上でWebAuthnとCTAPが役割を分担し、その仕組みで作られる資格情報がパスキー、そのパスキーを使う際の本人確認が生体認証やPIN、という関係です。「生体認証＝パスキー」ではない点を押さえておくと、仕組みの理解がぶれません。
出典・参考資料（2件）
- 出典：Passkeys（Passwordless Authentication）｜FIDO Alliance（https://fidoalliance.org/passkeys/）
- 出典：Web Authentication: An API for accessing Public Key Credentials – Level 2｜W3C Recommendation（https://www.w3.org/TR/webauthn-2/）
同期パスキーとデバイス固定パスキーの違い・端末を無くしたら
「端末を無くしたらログインできなくなるのでは」という不安は、パスキーでよく挙がる疑問です。これは、パスキーに2つのタイプがあることを知ると整理できます。技術的には、パスキーは同期パスキーとデバイス固定（デバイスバウンド）パスキーの2種類に分かれます。
- 同期パスキー：クラウド経由で複数の端末に同期されるパスキーです。iCloudキーチェーンやGoogleパスワードマネージャーなどが代表例で、端末を機種変更したり買い替えたりしても、同じアカウントでサインインすれば別の端末で復元して使えます。iCloudキーチェーンやGoogleパスワードマネージャーなどの主要な同期では、同期の際も暗号化され、事業者が秘密鍵の中身を読めない形で扱われます。
- デバイス固定（デバイスバウンド）パスキー：単一の認証器に紐づき、その端末の外に出ないパスキーです。FIDOセキュリティキーなどが代表例で、鍵が端末外に複製されない分だけ厳格に管理できます。
普段スマートフォンでサービスにログインする同期パスキーであれば、端末を紛失しても、同じクラウドアカウントで別の端末にサインインすればパスキーを復元できます。一方、デバイス固定パスキーは端末外に出ないため、紛失に備えて複数の認証器をあらかじめ登録しておく、リカバリー用の手段を用意しておく、といった対策が重要になります。
自分が使っているのがどちらのタイプかは、利用しているサービスや端末の設定で変わります。多くの一般向けサービスでは同期パスキーが使われるため、「端末を無くしたら即アウト」というわけではない、と理解しておくとよいでしょう。
出典・参考資料（2件）
- 出典：Terms（Synced passkey / Device-bound passkey の定義）｜passkeys.dev（FIDO Alliance）（https://passkeys.dev/docs/reference/terms/）
- 出典：Passkeys on Google Password Manager（エンドツーエンド暗号化の説明）｜Chrome Developers（https://developer.chrome.com/blog/passkeys-gpm-desktop）
パスキーのメリットと導入時の注意点
仕組みを踏まえたうえで、パスキーの利点と、導入・移行にあたって知っておきたい注意点を整理します。
パスキーの主なメリット（強固なセキュリティと使いやすさ）
パスキーの利点は、安全性と使いやすさの両立にあります。前半で見たとおり、共有する秘密がなく、鍵がドメインに紐づくため、フィッシングや漏洩に構造的に強いのが特徴です。
利用者から見た手軽さも見逃せません。長く複雑なパスワードを覚えたり入力したりする必要がなくなり、顔認証や指紋認証でそのままログインできます。パスワードの再設定や使い回しの管理から解放される点も、日々の負担を減らします。
導入・移行時の注意点と安全な運用
一方で、パスキーは「絶対に安全」と言い切れるものではなく、移行期ならではの注意点もあります。導入を検討する際は次の点を押さえておくとよいでしょう。
- 対応サービスはまだ広がり途上：主要なサービスは対応が進んでいますが、すべてのサービスやシステムが対応しているわけではありません。当面はパスワードとの併用が続く場面も多くあります。
- バックアップ手段を用意する：端末の紛失や故障に備え、複数端末への登録やリカバリー手段を準備しておくと安心です。特にデバイス固定パスキーでは重要になります。
- 段階的な移行とユーザーへの周知：企業が自社サービスに導入する場合は、既存のパスワードログインを残しつつ段階的に移行し、利用者に使い方を案内することが円滑な定着につながります。
- 端末とクラウドアカウントの保護は引き続き重要：仕組みが強固でも、端末のロック（生体認証・PIN）や、同期パスキーを預けるクラウドアカウントが破られれば、パスキーも悪用されかねません。端末のロックとクラウドアカウントの保護は併せて維持します。
パスキーの普及状況と今後の見通し
パスキーが広がる土台となったのが、主要プラットフォームの対応です。2022年5月、Apple・Google・Microsoftの3社が、共通のパスワードレスサインイン標準への対応を拡大する計画を表明しました。これにより、多くの利用者が特別な準備なしにパスキーを使える環境が整いました。
現在では多くのオンラインサービスがパスキーに対応し始めており、今後も対応は広がっていくと見られます。ただし普及は進行中の段階であり、利用できる範囲は使うサービスや端末によって異なります。自社サービスへの導入を考える場合も、利用者の環境を踏まえた設計が求められます。
出典・参考資料（1件）
- 出典：Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard to Accelerate Availability of Passwordless Sign-Ins（2022年5月5日）｜FIDO Alliance（https://fidoalliance.org/apple-google-and-microsoft-commit-to-expanded-support-for-fido-standard-to-accelerate-availability-of-passwordless-sign-ins/）
自社サービスにパスキーを導入・実装するには
ここからは、自社のアプリやWebサービスにパスキーを取り入れたい開発・プロダクト部門に向けて、実装の選択肢を整理します。パスキーに対応するには、大きく2つの進め方があります。
1つは、WebAuthnやFIDO2のサーバー機能を自前で実装する方法です。仕様に沿って公開鍵の登録・署名の検証・チャレンジの発行などを作り込む必要があり、自由度は高い反面、実装と保守の負担は小さくありません。
もう1つは、パスキー（FIDO2／WebAuthn）に対応した認証基盤やIDaaS（ID管理をクラウドで提供するサービス）、認証SDKを利用する方法です。パスキーの登録・認証のロジックを既製の基盤に任せられるため、自前実装の負担を抑えつつ短期間で対応できます。
ここでは、パスキー（FIDO2／WebAuthn）に対応した認証基盤・IDaaS・SDKをご紹介します。
| サービス名 | Auth0（Okta Customer Identity Cloud） | Amazon Cognito | Microsoft Entra External ID | PingOne（PingOne for Customers） | Keycloak | Uni-ID Libra |
|---|---|---|---|---|---|---|
| 提供形態 | クラウド（SaaS） | クラウド（AWSマネージド） | クラウド（Azure） | クラウド（SaaS） | オープンソース（セルフホスト） | オンプレミス／クラウド |
| パスキー対応プラン・条件 | 全プランで対応（Free含む・追加費用なし）。パスワードとの併用が前提、1ユーザー最大20個 | Essentials・Plusプランで対応（Liteは非対応）。パスワード等との併用が前提、1ユーザー最大20個 | 全プランで追加費用なし。登録できるのはメール／ユーザー名＋パスワードのローカルアカウントのみ | Plusプラン（年額5万ドル〜）にFIDO2対応を含む。Essentialは対象外、専用のパスワードレスソリューションは要問い合わせ | バージョン26.4以降で公式サポート（OSSのためライセンス費用なし）。管理コンソールで有効化 | FIDO全方式に対応（FIDOユニバーサルサーバ認定）。2023年にパスキー対応、料金は要問い合わせ |
| 特徴 | ログイン機能を外部サービスとして組み込めるCIAM。Web向けUniversal Login・ネイティブアプリ・モバイルの複数実装形態に対応し、段階的なパスキー登録もできる | AWS上でサービスを構築している場合に同じ基盤でユーザー認証をまとめられるマネージド認証（User Pools）。マネージドログインで処理するほかAPIで独自実装も可能 | Azure AD B2Cの後継CIAM。登録画面は組み込みでは提供されず、Microsoft GraphのAPIで自社側の実装が必要。Microsoft製品で揃えたい企業向け | ノーコードのオーケストレーション（DaVinci）で認証フローを構築。FIDO2ポリシーで同期パスキーの許可可否を制御でき、大規模・複雑な認証要件に対応 | 自社サーバーに導入するOSSのID管理ソフト。Conditional UIとModal UIに対応し、パスワードログインも併用できる。外部サービスに依存せず自社管理したいチーム向け | NRIセキュアが提供する国産のID統合基盤。パスキー追加のみの独立製品「Uni-ID Libra FIDO」をAPI連携で利用でき、要件定義から日本語で支援 |
| 詳細情報 | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る |
※対応プラン・料金は2026年10月時点の各社公式情報によります。最新の提供条件は各社公式サイトでご確認ください。
Auth0（Okta Customer Identity Cloud）（Okta, Inc.）
Auth0は、Okta社が提供する顧客向けID管理（CIAM）の基盤で、ログイン機能を外部サービスとして組み込めるのが特徴です。自社でサインイン画面やユーザー管理を一から作らずに、認証まわりを任せられます。
パスキー認証は2024年2月に一般提供となり、公式の料金ページではFreeを含む全プランで追加費用なしの機能として提供されています。
Webアプリ向けのUniversal Login、ネイティブアプリ向けのEmbedded Login、モバイル向けのネイティブパスキーと、複数の実装形態が用意されています。パスワードでログインした後にパスキー作成を促す段階的な登録にも対応し、幅広いプランでまず試しやすいのが利点です。
Amazon Cognito（Amazon Web Services, Inc.）
AWSのマネージド認証サービスであるAmazon Cognitoは、User Poolsというユーザーディレクトリ機能でサインアップ・サインインを担います。AWS上でサービスを構築している場合に、同じ基盤でユーザー認証をまとめられる点が強みです。
パスキー認証（WebAuthn／FIDO2）はEssentials・Plusの各プランで利用でき、Liteプランでは対象外です。マネージドログインを使えばCognitoがパスキーのロジックを処理し、独自に作り込む場合はUser Pools APIからバックエンドで実装できます。1ユーザーあたり最大20個のパスキーを登録でき、既存のAWS構成に認証を組み込みやすいのが特徴です。
Microsoft Entra External ID（Microsoft Corporation）
Microsoft Entra External IDは、Microsoftが提供する顧客・外部ユーザー向けのID管理サービスです。Azure AD B2Cの後継にあたり、自社サービスの会員認証基盤として利用できます。
外部テナント向けにパスキー（FIDO2）でのサインインに対応しており、パスキー自体の追加費用はかかりません。ただし、現時点でパスキーを登録できるのはメールまたはユーザー名とパスワードのローカルアカウントに限られます。
登録画面は組み込みでは提供されず、Microsoft GraphのAPIを使って自社側で実装する必要があります。Microsoft製品でシステムをそろえたい企業に向いた選択肢ですが、導入時は対応範囲の確認が欠かせません。
PingOne（PingOne for Customers）（Ping Identity）
PingOne for Customersは、Ping Identityが提供する顧客向けのクラウド型ID管理基盤です。認証・ユーザー管理・多要素認証（MFA）を、コードを書かずに組み合わせられるオーケストレーション機能を備えます。
パスキー・FIDO2は認証方式として対応しており、公式の料金ページではPlusプラン（年額5万ドル〜）に「FIDO2 bound biometrics and security keys」のサポートが含まれると記載されています。
FIDO2ポリシーとMFAポリシーを設定して利用する構成で、同期パスキーを許可するかどうかもポリシーで制御できます。大規模で複雑な認証要件を持つ顧客基盤に向いています。
Keycloak（Keycloakプロジェクト／主要スポンサー：Red Hat）
Keycloakは、CNCF（Cloud Native Computing Foundation）配下で開発が進むオープンソースのID管理ソフトウェアです。自社のサーバーに導入して運用でき、ライセンス費用がかからないため、認証基盤を内製・自社管理したい開発チームに向いています。
パスキーはバージョン26.4以降で公式サポート機能として提供され、管理コンソールで有効化します。ユーザー名欄をクリックするとブラウザのオートフィルにパスキーが現れるConditional UIと、ボタンでダイアログを出すModal UIの両方に対応し、パスワードログインも併用できます。
オープンソースで自由にカスタマイズしたい企業や、外部サービスに依存せず自社で認証基盤を持ちたい開発チームに適しています。
Uni-ID Libra（NRIセキュアテクノロジーズ株式会社）
Uni-ID Libraは、NRIセキュアテクノロジーズが提供する国産のID管理基盤です。日本語でのサポートや国内事業者向けの実績を重視する企業にとって、相談しやすい選択肢といえます。
製品ページでは、パスワードレス標準規格FIDOの全方式に対応し、スマートフォンやPCに組み込まれた指紋認証・顔認証を使ったパスワードレス認証を実現できるとしています。2023年にパスキーへ対応しています。
既存のID基盤にパスキー認証だけを追加できる「Uni-ID Libra FIDO」という独立製品も用意され、APIを呼び出すだけでパスキーの登録・認証のサーバー機能を利用できます。既存システムへ段階的に組み込みたい場合に検討しやすい構成です。
ここで取り上げた6サービスのほかにも、生体認証・パスキーに対応した認証基盤やSDK/APIは複数あります。各サービスの機能・料金を横並びで比較し、自社に合うものの選び方まで確認したい場合は、以下の記事が参考になります。
パスワードレス認証とは？自社サービスに組み込む生体認証・パスキー対応SDK/APIを機能・料金で比較【選び方も解説】
自社アプリやWebサービスのログインを、パスワードに頼らない方式へ切り替えたいと考える開発・プロダクト部門が増えています。パスワードの使い回しやフィッシングによる不正ログインが後を絶たず、パスキーやFIDO2といったパスワードレス認証が、そ…
まとめ
パスキーは、端末内で作った秘密鍵と、サービスに預けた公開鍵のペアで本人確認を行う、公開鍵暗号にもとづくパスワードレス認証です。登録では公開鍵だけがサービスに渡り、ログインではチャレンジに秘密鍵で署名してサービスが公開鍵で検証します。
秘密鍵が端末内に保持されて認証のたびにネットワークへ送られず、鍵がサービスのドメインに紐づくため、パスワードにつきものの漏洩・使い回し・フィッシングといった弱点に構造的に対処できます。生体認証やPINは、その秘密鍵を使うための本人確認であり、生体情報自体がサービスに送られるわけではありません。
自社サービスへの導入を考えるなら、WebAuthn／FIDO2を自前で実装するほか、パスキーに対応した認証基盤・IDaaS・SDKを使う方法があります。対応状況やプランはサービスごとに異なるため、自社の構成と要件に合うものを比較して、導入の検討を進めてください。
よくあるご質問（FAQ）
Q. パスキーとは何ですか？
A. パスキーとは、FIDO（ファイド）という業界標準にもとづく、公開鍵暗号を使ったパスワードレス認証の資格情報です。端末内で作った秘密鍵と、サービスに預けた公開鍵のペアで本人確認を行い、パスワードの代わりにログインに使います。パスワードのように「本人とサービスが同じ秘密の文字列を共有する」方式ではないため、仕組みそのものがフィッシングや漏洩に強いのが特徴です。
Q. パスキーとパスワードは何が違うのですか？
A. パスキーとパスワードの最大の違いは、本人とサービスが同じ秘密を共有するかどうかにあります。パスワードは本人とサービスが同じ秘密の文字列を共有するのに対し、パスキーではサービスが公開鍵しか持たず、秘密鍵は端末内に保持されて認証のたびにネットワークへ送信されることはありません。そのため、漏洩・使い回し・フィッシングといったパスワードの弱点に構造的に強くなります。
Q. パスキーは指紋認証や顔認証のことですか？
A. パスキーと生体認証は別のもので、指紋認証や顔認証・PINは、パスキーの秘密鍵を使うための本人確認（ユーザー検証）の手段です。生体認証そのものがパスキーなのではありません。顔や指紋といった生体情報は端末内で照合され、サービス側（サーバー）に送られることはなく、サービスに届くのは秘密鍵で作られた署名だけです。
Q. パスキーはなぜフィッシングに強いのですか？
A. パスキーがフィッシングに強いのは、鍵のペアが登録したサービスのドメイン（オリジン）に紐づいているためです。本物そっくりの偽サイトにアクセスしても、ドメインが一致しなければパスキーでの認証は成立しません。利用者が偽サイトを見分けられなくても、仕組みの側でフィッシングを防げる点が、パスワードとの決定的な違いです。
Q. スマートフォンを紛失したらパスキーでログインできなくなりますか？
A. パスキーを紛失時に復元できるかは、使っているのが同期パスキーかデバイス固定パスキーかによって変わります。クラウド経由で複数の端末に同期される同期パスキーであれば、別の端末で同じアカウントにサインインすればパスキーを復元できます。
端末外に出ないデバイス固定（デバイスバウンド）パスキーの場合は、紛失に備えてあらかじめ複数の認証器を登録したり、リカバリー手段を用意したりしておくことが重要です。多くの一般向けサービスでは同期パスキーが使われるため、「端末を無くしたら即アウト」とは限りません。
Q. 機種変更をするとパスキーは引き継げますか？
A. 同期パスキーであれば、機種変更後の端末で同じクラウドアカウントにサインインすることで、パスキーを引き継いで使えます。iCloudキーチェーンやGoogleパスワードマネージャーなどが代表例です。一方、デバイス固定（デバイスバウンド）パスキーは端末外に出ないため引き継げず、新しい端末であらためて登録し直す必要があります。
Q. パスキーを使うには何が必要ですか？
A. パスキーを使うには、生体認証やPINに対応した端末と、パスキー（FIDO2／WebAuthn）に対応したサービスの両方が必要です。Apple・Google・Microsoftの主要プラットフォームが対応したことで、多くの利用者は特別な準備なしにパスキーを使える環境が整っています。ただし、実際に利用できる範囲は使うサービスや端末によって異なります。
Q. パスキーはすべてのサービスで使えますか？
A. パスキーはすべてのサービスで使えるわけではなく、対応は主要サービスを中心に広がり途上の段階です。まだパスキーに対応していないサービスやシステムも多く、当面はパスワードとの併用が続く場面も少なくありません。利用中のサービスがパスキーに対応しているかは、各サービスのログイン・セキュリティ設定で確認できます。
Q. 自社サービスにパスキーを導入するには何が必要ですか？
A. 自社サービスにパスキーを導入するには、WebAuthn／FIDO2のサーバー機能を自前で実装する方法と、パスキーに対応した認証基盤・IDaaS・認証SDKを利用する方法の、大きく2つがあります。自前実装は自由度が高い反面、公開鍵の登録・署名の検証・チャレンジの発行などを作り込む負担が小さくありません。
既製の認証基盤を使えば、パスキーの登録・認証のロジックを任せて短期間で対応できます。対応プランや実装方式はサービスごとに異なるため、自社の構成と要件に合うものを比較して選ぶとよいでしょう。
法人向けサービスを課題別に探すならMCB FinTechカタログ
MCB FinTechカタログでは、決済・金融・バックオフィス領域の法人向けサービスを課題別に探し、気になるサービスの資料をまとめて請求できます。生体認証・パスキー認証SDKのほかの課題も、あわせてご確認ください。
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
