パスワードレス認証とは？自社サービスに組み込む生体認証・パスキー対応SDK/APIを機能・料金で比較【選び方も解説】

自社アプリやWebサービスのログインを、パスワードに頼らない方式へ切り替えたいと考える開発・プロダクト部門が増えています。パスワードの使い回しやフィッシングによる不正ログインが後を絶たず、パスキーやFIDO2といったパスワードレス認証が、その現実的な対策として広がってきたためです。

一方で、いざ自社サービスへ組み込もうとすると、「FIDO2やWebAuthnを自前で実装するのか、認証SDK・APIやCIAMを導入するのか」「どのサービスが自社の要件に合うのか」という判断で迷いがちです。自社に合う一社を選ぶには、機能・料金・提供形態を横断で見比べる必要があります。

本記事では、自社サービスのエンドユーザー向け本人認証を組み込むための認証SDK・API・CIAM(顧客ID＆アクセス管理)を、機能・料金・提供形態・日本語サポートの観点で横断比較します。パスキー/FIDO2の仕組みをFIDO AllianceやNIST（米国国立標準技術研究所）の一次情報にもとづいて正確に押さえたうえで、「自前実装か導入か」の判断軸と、用途別の選び方まで整理しました。

プロダクトの認証を刷新したい担当者が、自社に合う手段を判断するための材料としてご活用ください。

本記事では、主要な認証SDK・API・CIAM 12サービスを取り上げます。「国内SaaS・導入支援型」「生体認証・パスキーSDK特化型」「開発者向けCIAMプラットフォーム型」「大企業・エンタープライズ統合型」「特定機能をAPIで組み込むコンポーネント型」の5つの切り口で整理しています。

また、自社の状況に合う認証サービスを最短で見つけられるよう、「30秒で終わる選定診断ツール」をご用意しています。ぜひこちらもご活用ください。

パスワードレス認証とは？

パスワードレス認証とは、IDとパスワードの組み合わせに頼らず、生体情報や端末に保存した鍵、ワンタイムコードなどを使って本人を確認するログイン方式の総称です。パスワードそのものを利用者に入力させないことで、盗まれる・使い回される・推測されるといったパスワード起因のリスクを根本から減らすことをねらいます。

なかでも近年の中心にあるのが「パスキー(passkey)」です。FIDO Allianceはパスキーを、端末のロック解除と同じ操作(生体認証・PIN・パターン)でアプリやサイトにサインインできるFIDO認証情報だと定義しています。利用者はユーザー名やパスワード、追加の認証要素を入力する必要がなくなります。

本記事は、こうしたパスワードレス認証を自社サービスのエンドユーザー(顧客・会員)向けに組み込むケースを対象にしています。社内の従業員アカウントを守る多要素認証(MFA)とは目的も選ぶ製品も異なるため、その違いも後述します。

出典・参考資料（1件）

• 参考資料：Passkeys｜FIDO Alliance（https://fidoalliance.org/passkeys/）

パスワード認証の課題とパスワードレス化が進む背景

パスワード認証には、構造的な弱点があります。利用者が複数のサービスで同じパスワードを使い回すと、どこか1か所の漏えいが芋づる式の不正ログイン(リスト型攻撃)につながります。偽サイトに誘導してパスワードを入力させるフィッシングも、パスワードが「利用者が入力してネットワークに送る秘密」である限り避けにくい攻撃です。

こうした脅威は一過性のものではありません。情報処理推進機構(IPA)の「情報セキュリティ10大脅威 2025」でも、個人向けの脅威として「インターネット上のサービスへの不正ログイン」と「フィッシングによる個人情報等の詐取」が継続して選出されています。自社サービスの利用者を守る観点でも、パスワードに依存しない認証への移行が現実的な選択肢になってきました。

出典・参考資料（1件）

• 参考資料：情報セキュリティ10大脅威 2025｜情報処理推進機構(IPA)（https://www.ipa.go.jp/security/10threats/10threats2025.html）

従業員向け多要素認証(MFA)との違い

認証サービスを探すと、従業員向けの多要素認証(MFA)やシングルサインオン(SSO)の製品も数多く見つかります。ただし、これらは守る対象が異なります。

従業員向けMFAやIDaaSは、社内システムやSaaSにログインする「自社の従業員アカウント」を保護する情報システム部門向けの仕組みです。対して本記事が扱う認証SDK・API・CIAMは、自社が提供するサービスにログインする「エンドユーザー(顧客・会員)のアカウント」を保護するものです。

想定するユーザー数の規模、求められる登録・ログイン体験、料金モデルがいずれも異なるため、製品選びの出発点から分けて考える必要があります。

もし探しているのが自社サービスの会員ではなく、社内システムやSaaSにログインする従業員アカウントを守る仕組みであれば、認証方式・料金・タイプ別に多要素認証(MFA)システムを比較した以下の記事が参考になります。

パスワードレス認証の種類(パスキー/FIDO2・生体・デバイス・マジックリンク・SMS/OTP・ソーシャル)

ここからは、パスワードレス認証を実現する主な方式を整理します。方式によって安全性の水準や利用者の手間、向いているサービスが異なります。自社サービスにどれを採り入れるかを判断できるよう、代表的な6方式を同じ粒度で並べます。

※上記は一般的な傾向です。実際の対応方式は各サービスの公式情報をご確認ください。

これらは排他的なものではなく、実際のサービスでは複数を組み合わせて提供されます。とくにパスキー/FIDO2は、後述するとおりフィッシング耐性の高さから中心的な選択肢になりつつあります。

パスキー/FIDO2の仕組みとフィッシングに強い理由

ここからは、パスキー/FIDO2がなぜ安全とされるのかを、規格の一次情報にもとづいて解説します。仕組みを理解しておくと、後半の選び方や自前実装の判断でも迷いにくくなります。

公開鍵暗号にもとづく仕組みと登録・認証フロー

パスキー/FIDO2は、公開鍵暗号という技術にもとづいています。利用者がサービスにパスキーを登録すると、そのサービス・そのアカウント専用の鍵ペア(秘密鍵と公開鍵)が生成されます。秘密鍵は利用者の端末(または資格情報マネージャ)にとどまり、公開鍵だけがサービス側に登録されます。

ログイン時は、サービスから送られた課題(チャレンジ)に対し、端末内の秘密鍵で署名を返し、サービスは登録済みの公開鍵で検証します。秘密鍵そのものはネットワークを流れず、公開鍵から秘密鍵を計算で割り出すこともできません。指紋や顔などの生体情報は端末内での本人確認に使われるだけで、外部には送られない実装が基本です。この点はAppleの公式解説でも次のように説明されています。

One of these keys is public, and is stored on the server. This public key is not a secret. The other key is private, and is what is needed to actually sign in. The server never learns what the private key is.

Apple「About the security of passkeys」(https://support.apple.com/en-us/102195)

この登録と認証の流れを図にすると、次のようになります。

この仕組みの土台になっているのが、W3Cが2021年4月に勧告(Recommendation)として公開したWebAuthn(Web Authentication)というブラウザ向けのAPIです。

FIDO2は、このWebAuthnと、端末と認証器の間の通信を定めるCTAP(Client to Authenticator Protocol)を組み合わせた認証標準で、パスキーはこのFIDO2の仕様の上に構築されています。

出典・参考資料（3件）

• 出典：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/）
• 出典：About the security of passkeys｜Apple（https://support.apple.com/en-us/102195）

フィッシング・不正ログインに強い理由

パスキーがフィッシングに強い最大の理由は、鍵が登録したドメインに束縛されている点にあります。Microsoftの解説では、netflix.com向けに作られたパスキーはnetflix.comでしか使えず、よく似た偽サイトに誘導されても端末がその偽サイトへパスキーを提示しないと説明されています。

For example, a passkey created for netflix.com can only be used with netflix.com. While you may be tricked into landing on a similar looking website, your device won’t present your passkey to the malicious website.

Microsoft「What are passkeys and why they matter」(Microsoft Support)

米国国立標準技術研究所(NIST)は、フィッシング耐性を「利用者の注意深さに頼らずに、認証の秘密や有効な認証出力を、検証者になりすました攻撃者へ開示させないこと」と定義しています(SP 800-63B-4)。パスキー/FIDO2は、秘密情報を送らず・偽サイトに鍵を出さない仕組みによって、この定義を技術的に満たします。

SMSのワンタイムコードのように利用者がコードを読み上げて盗まれる余地がない点が、従来の方式との違いです。

ただし、注意も必要です。NISTのガイドラインでは、複数端末に同期される同期型パスキーは秘密鍵が持ち出せる性質があるため、最高保証水準であるAAL3の認証器としては用いないものとされています。フィッシング耐性は十分に高い一方で、「パスキーだから常に最高保証水準を満たす」と一律に言えるわけではない点は、社内での説明時に押さえておくことが重要です。

出典・参考資料（2件）

• 出典：SP 800-63B-4 Digital Identity Guidelines: Authentication and Authenticator Management, §2.2.2 / §2.3.2 / §3.2.5｜NIST（https://pages.nist.gov/800-63-4/sp800-63b.html）
• 出典：What are passkeys and why they matter｜Microsoft（Microsoft Support）

パスワードレス認証を導入するメリット

自社サービスにパスワードレス認証を組み込むと、セキュリティと利用者体験の両面で効果が期待できます。ここでは主な便益を整理します。

第一に、フィッシングやリスト型攻撃といったパスワード起因の不正ログインを大きく減らせます。前述のとおり、鍵がネットワークを流れず、登録ドメイン以外には提示されないため、利用者が偽サイトにだまされても被害につながりにくくなります。

第二に、ログイン体験が快適になります。利用者はパスワードを覚えたり入力したりする必要がなく、端末のロック解除と同じ操作でサインインできます。FIDO Allianceは、パスキーによってパスワードと比べてサインインの成功率が20%向上したと公表しており、入力の手間やパスワード忘れによる離脱を減らす効果が見込めます。

第三に、パスワードの保管・リセット対応にかかる運用負担を軽減できます。パスワードリセットの問い合わせ対応や、漏えい時のパスワード変更の一斉通知といった作業を減らせる点は、サービス運営側にとっての実務的な利点です。

出典・参考資料（1件）

• 参考資料：Passkeys｜FIDO Alliance（https://fidoalliance.org/passkeys/）

自前実装(FIDO2/WebAuthn)と認証SDK・API・CIAM導入のどちらを選ぶか

パスワードレス認証を組み込むとき、開発現場が最初に迷うのが「FIDO2/WebAuthnを自前で実装するか、認証SDK・API・CIAMを導入するか」です。ここでは判断材料を、工数・専門知識・料金・保守の4点で整理します。

自前実装は、WebAuthnがブラウザ標準のAPIであるため、小規模であれば実装自体は可能です。外部サービスへの月額費用も発生しません。反面、パスキーの登録・認証フロー、複数端末での同期や機種変更時の復旧、対応OS・ブラウザの差異、アカウント回復の設計などを自社で作り込み、規格の更新にも追随し続ける必要があります。

認証はサービスの根幹であり、不具合が全利用者のログイン不能に直結します。しかもこれらは一度作れば終わりではなく、OS・ブラウザの更新や規格改定のたびに検証・改修が続き、障害監視や不正利用の監視も含めた保守が継続的に発生します。自社サービスとして認証の中核を継続的に抱えられるかが、自前実装を選べるかの分かれ目になります。

認証SDK・API・CIAMの導入は、これらの作り込みと保守を外部に委ねられる点が利点です。パスキーだけでなくソーシャルログインやSMS/OTP、多要素認証などを設定で切り替えられ、規格更新への追随もサービス側が担います。一方で、利用者数(MAU)などに応じた費用がかかり、認証基盤を外部に依存することになります。

目安としては、認証を差別化要素にせず早く安全に立ち上げたい、専任の認証エンジニアを抱えにくい、複数の認証方式を将来的に切り替えたい、といった場合は導入が向きます。逆に、認証まわりの要件が特殊で細部まで自社で制御したい、外部依存を避けたい明確な理由がある場合は自前実装や、あとで触れるオープンソースの自社構築が候補になります。自社がどちらに当てはまるかは、次の診断ツールでも確認できます。

自社の目的や体制に合った認証サービスのタイプを知りたい方に向けて、かんたんな質問に答えるだけで候補が絞り込める診断ツールをご用意しました。

認証SDK・API・CIAMの選び方(比較軸)

導入を選ぶ場合、どのサービスが自社に合うかを見極める軸が必要です。ここでは、後半の比較表と対応する4つの観点を挙げます。

対応する認証方式と提供形態が自社に合うか

まず、自社が使いたい認証方式(パスキー/FIDO2・生体・SMS/OTP・ソーシャルログインなど)に対応しているかを確認することが出発点です。あわせて提供形態も見極めることが重要です。認証画面まで含めて丸ごと提供するフルスタックのCIAM、自社アプリに組み込むSDK、認可の中核だけをAPIで提供するもの、オープンソースで自社構築するものなど、形態によって作り込みの自由度と運用負担が変わります。

iOS・Android・Webなど自社が提供するプラットフォームを広くカバーしているかも、このタイミングで確認しておくことが重要です。

料金・課金モデルの見方（MAU課金・月額・無料枠）は自社の規模に見合うか

顧客向け認証サービスの多くは、月間アクティブユーザー数(MAU)に応じた従量課金や、無料枠＋段階的な有料プランという料金体系をとります。自社サービスの利用者規模が大きい場合、MAU課金は成長に伴って費用が膨らむため、無料枠の範囲・課金の刻み・上位プランの単価を試算して比較することが重要です。

オープンソースを自社構築する場合は月額費用こそ抑えられますが、その分の構築・運用の人件費を織り込んで判断します。

日本語サポート・国内導入支援があるか

海外製のサービスは機能が豊富な一方、ドキュメントや問い合わせが英語中心のことがあります。認証はトラブルが利用者のログイン不能に直結するため、障害時に日本語で迅速にやり取りできるか、国内に導入支援や代理店があるかは実務上の重要な分岐点です。社内に英語で一次情報を追える体制があるかどうかで、許容できる範囲が変わります。

この点で、日本法人や日本語サイト・ドキュメントがあることと、国内代理店による導入支援や障害時の日本語対応があることは別の軸です。本記事の比較表と診断ツールは、この粒度で両者を見分けています。

エンタープライズ要件(SLA・マルチテナント・コンプライアンス)を満たすか

大規模サービスやグループ企業での利用、金融・公共など高い要件が求められる領域では、稼働率を保証するSLAや各種コンプライアンス認証への対応が選定を左右します。複数ブランド・事業を分離するマルチテナント対応も要点です。金融グレードのAPI(FAPI)への準拠が必要な場合は、その対応可否も確認します。自社が現時点で必要とする水準と、将来の拡大を見据えた水準の両方で見ておく必要があります。

用途別の使い分け(自社サービスのログイン／決済・取引認証／会員基盤)

認証をどのシーンで使うかによって、重視すべきサービスの性質は変わります。自社の用途に引きつけて考えると、選択肢を絞り込みやすくなります。

一般的な会員サービスやアプリのログインが主目的なら、パスキーやソーシャルログインに手早く対応でき、登録・ログイン体験を作り込みやすい開発者向けCIAMプラットフォーム型が向きます。具体的なサービス名は、後述の比較表と診断ツールで確認できます。

決済・送金・取引の承認など、より高い確実性が求められる本人認証では、フィッシング耐性の高いパスキーに加え、金融グレードのAPI(FAPI)への準拠や継続的な本人確認まで視野に入ります。FAPIに対応する認証コンポーネント特化型や、継続的な本人確認ができる生体認証・パスキーSDK特化型が候補になります。

大規模な会員基盤やグループ横断のID統合が主眼なら、マルチテナントや既存IDとの連携に強い大企業・エンタープライズ統合型が候補です。

なお、本記事が扱う「本人認証」は、ログイン時に「登録済みの本人か」を確かめる仕組みです。これに対し、口座開設や会員登録の時点で「実在する本人か」を運転免許証やマイナンバーカードなどで確かめるeKYC(オンライン本人確認)は別の仕組みで、金融・決済サービスでは両方が必要になることが多くあります。eKYCを自社アプリ・Webへ組み込む方式や選び方は、以下の記事で比較しています。

次の比較表では、これらの用途の違いも踏まえて各サービスの性質を並べています。

【比較表】認証SDK・API・CIAMサービス12選の比較

ここまでの選び方をふまえ、主要な認証SDK・API・CIAM 12サービスを横断で比較します。パスキー/FIDO2への対応、提供形態、料金モデル、日本語サポート、エンタープライズ要件（SLA・FAPI等）を一覧で確認できます。表はタイプ別に並べています。サービス名をクリックすると、各サービスの詳細説明に移動します。

※米ドル・ユーロ建ての料金は為替レートにより日本円換算額が変動します。

※上記は一般的な傾向です。実際の機能搭載の有無や料金は各社情報をご確認ください。

各認証SDK・API・CIAMサービスの詳細

ここからは、比較表で取り上げた各サービスを、提供形態や強みの違いにそって5つの切り口に分けて紹介します。自社の目的に近いタイプから読み進めてください。

国内SaaS・導入支援型(日本語サポートで導入しやすい)

日本語のサポートや導入支援を受けながら、自社サービスの会員ログイン基盤を整えたい企業に向くタイプです。

1. Login3.0（株式会社UPBOND）

DID(分散型ID)/VC(検証可能な資格情報)技術をベースに、株式会社UPBONDが開発した顧客・エンドユーザー向けのログイン基盤(CIAM)が、Login3.0です。サービスごとにIDを発行するのではなく、複数サービスで共通して使えるID(DID)を発行し、単一のIDでログインできるシングルサインオンを実現します。

個人情報をブロックチェーン上に公開しない設計で、Web3.0技術はユーザーID(DID)の発行のみに使われます。既存システムとはSDK経由で連携でき、実装を簡素化できます。同意管理と法令に準拠したデータ取得を前提に、グループ企業間でIDを連携させ、顧客同意済みのファーストパーティデータを統合できる点が、単なる認証機能にとどまらない特徴です。

2025年3月に加わったLogin3.0 with AI Agentでは、同意のうえ蓄積したライフログを複数のLLM(ChatGPT・Gemini・Claudeなど)と組み合わせ、SNSやチャットボット経由の顧客対応をパーソナライズできます。料金は公開されておらず要問い合わせです。自社サービスの会員ログインを統合しつつ、蓄積した顧客データの活用まで視野に入れたい企業に向く選択肢です。

生体認証・パスキーSDK特化型

顔・声紋・行動的特徴などの生体認証やパスキーを、自社アプリに組み込むSDKに強みを持つタイプです。継続的な本人確認まで踏み込みたいサービスに向きます。

2. DZ Security®（株式会社AnchorZ）

特許を取得した「バックグラウンド認証®」を中核に、株式会社AnchorZが自社開発した本人認証プラットフォームです。ログイン時の一度きりの認証ではなく、サービスの利用中ずっとバックグラウンドで本人確認を続ける方式を採ります。

認証には顔認証・声紋認証といった生体情報に加え、スマートフォンの持ち方や利用場所・時間帯などの行動的特徴を組み合わせます。認証データは端末内に保存しサーバーへ送信しない設計とされており、事業者が生体データを自社サーバーに保持せずに運用できる点を訴求しています。

開発者向けには統合認証エンジン「SDK Analyca」を提供し、自社アプリへの組み込みに対応します。金融機関として初めて同技術を導入したきらぼし銀行のPC・内部システム向け「DZ Pass」や、なりすましによる不正転売を防ぐオンラインチケット購入アプリでの採用など、業種の異なる導入事例が公表されています。料金は公式に公開されておらず、初期費用・月額費用とも問い合わせが必要です。

このバックグラウンド認証®が従来の認証方式とどう異なるのかについて、開発元の株式会社AnchorZは、MCB FinTechカタログのインタビューで次のように説明しています。

開発者向けCIAMプラットフォーム型

REST APIやSDKが充実し、独自の登録・ログイン体験を作り込みながら会員認証基盤を構築したい開発チームに向くタイプです。

3. Auth0（Okta, Inc.）

米国Okta, Inc.傘下で提供される開発者向けの認証・認可プラットフォームが、Auth0です。Web・モバイル・APIアプリケーションにサインアップ、サインイン、SSO、MFA、ソーシャルログインを実装するためのSDK・API・管理ダッシュボードを備え、2021年の買収以降は顧客向けID管理「Okta Customer Identity Cloud」の中核技術として位置づけられています。

ホスト型のログイン画面「Universal Login」を軸に、Google・Appleなど74種類のソーシャル連携、WebAuthn/FIDO2によるパスキー、SAML/OIDC/AD・LDAPといったエンタープライズ連携に対応します。ログイン前後のイベントで動くサーバーレス関数「Actions」を使えば、認証フローに独自ロジックを組み込めます。

金融領域向けにはFAPI 1 Advanced認定やPSD2の強力な顧客認証(SCA)に対応しており、決済・金融サービスへ組み込む際に確認しておきたいポイントです。料金はMAU(月間アクティブユーザー数)課金で、25,000MAUまでの無料プランからEnterpriseまで用意されますが、公式料金ページは米ドル建てで、日本円建ての料金は要問い合わせとなります。

4. Amazon Cognito（Amazon Web Services, Inc.）

Amazon Cognitoは、会員登録・サインイン基盤の「User Pools」と、認証済みユーザーにAWSリソースへの一時的なアクセス権を発行する「Identity Pools」という2つのコンポーネントで構成される、AWSのマネージド型CIAMサービスです。

User Poolsはパスワードレス(パスキー・SMS/メールのワンタイムコード)、MFA、ソーシャル連携(Apple/Google等)、SAML/OIDCによるエンタープライズ連携に対応します。2024年11月からはLite・Essentials・Plusの3段階の機能プランに分かれ、Plusでは侵害済み認証情報の検知やリスクベースの適応型認証といった脅威保護を利用できます。

設計の前提はAWSエコシステムとの統合です。S3・DynamoDB・Lambda・API Gatewayと連携し、IAMロールでAWSリソースへのアクセスを制御できます。料金は完全従量課金で、Lite・Essentialsプランは月10,000MAUまで無料、超過分はEssentialsで$0.015/MAUなどのMAU単価で課金されます(米ドル建て)。AWSを基盤に開発するチームに向きます。

5. Firebase Authentication（Google LLC）

Googleのモバイル/ウェブアプリ開発プラットフォーム「Firebase」の一機能として提供されるエンドユーザー向け認証バックエンドが、Firebase Authenticationです。

iOS・Android・Web・Flutter・Unityなど幅広いプラットフォーム向けのSDKとUIライブラリを備え、メール/パスワード・電話番号(SMS)・匿名・メールリンク(パスワードレス)・Google/Appleなどのソーシャルログインを組み込めます。

注意したいのは無償版と有償版の機能差です。多要素認証(MFA)・SAML/OIDC連携・マルチテナントは無償版のFirebase Authenticationでは利用できず、有償版「Firebase Authentication with Identity Platform」へのアップグレードで初めて対応します。

PCI-DSSやBAA(HIPAA関連)、99.95%のSLAも同様にIdentity Platform側の対象で、規制業種の調達要件を満たすにはアップグレードが前提となります。

料金は完全従量課金で、メール・電話番号・ソーシャルなどの標準的な認証は50,000MAUまで無料、超過後はMAU単価で課金されます(米ドル建て)。小規模で始め、MFAやエンタープライズ機能が必要になった段階で、既存のSDKコードを保ったままIdentity Platformへ移行できる設計です。

6. Keycloak（Keycloakプロジェクト／主要スポンサー: Red Hat, Inc.）

Keycloakは、Apache License 2.0で公開されているオープンソースのID・アクセス管理(IAM)ソフトウェアです。CNCF(Cloud Native Computing Foundation)のインキュベーティングプロジェクトとして開発され、Red Hatが主要スポンサーとして関与しています。

ここまでの各サービスと大きく異なるのは、SaaSとして提供されるのではなく、自社のサーバー・コンテナ環境に自前で構築して運用するセルフホスト型である点です。ソフトウェアのライセンス費用は無償ですが、可用性設計・データベース連携・SSL/TLS設定・脆弱性パッチ適用などはすべて利用企業側が担い、Kubernetesやミドルウェア運用の専門知識が求められます。

機能面ではOIDC・OAuth 2.0・SAML 2.0を標準搭載し、SSO、パスキーやTOTPによる多要素認証、LDAP/Active Directory連携、管理コンソール、テーマのカスタマイズなど、商用CIAMと同等の機能セットを追加コストなく利用できます。

プロジェクト自体による日本語サポート窓口はなく、国内ではNRI(OpenStandia)やRed Hatなどが有償サポートを提供しています。

大企業・エンタープライズ統合型

大規模なユーザー数やグループ横断のID統合、既存システムとの連携、高いコンプライアンス要件に対応したい企業に向くタイプです。

7. Microsoft Entra External ID（Microsoft）

旧Azure AD B2Cの後継として、2024年5月に一般提供が始まったMicrosoftの顧客・外部ユーザー向けCIAMです。従業員向けID基盤のMicrosoft Entra ID(旧Azure Active Directory)に対し、こちらは自社アプリを利用する顧客・会員の認証を担う「外部テナント」を作成して構成します。

外部テナントでは、メールやパスワード、Google・Facebook・Appleのソーシャルログイン、SAML/WS-Fedフェデレーション、パスキー(FIDO2)などを組み合わせてサインアップ・サインインを設計できます。従業員向けと顧客向けで共通のMSAL SDKを使えるため、Azure・Microsoft環境で開発する企業は認証まわりの基盤をそろえやすい設計です。

料金は月間アクティブユーザー(MAU)課金で、最初の50,000 MAUまでは無料で利用を始められます。データ所在地要件に応えるGo-Localアドオンでは対象地域に日本が含まれます。一方で、外部テナントはMicrosoft 365などへのSSOやID Protectionといった従業員テナント向けの一部機能には対応しないため、必要要件との照合が必要です。

8. PingOne（Ping Identity）

Ping Identity(米国コロラド州デンバー、2002年創業)が提供する、クラウド型のアイデンティティ基盤「PingOne」上のCIAMです。顧客向けの製品ラインが「PingOne for Customers」で、公式サイトはFortune 100企業の半数以上で同社のID基盤が使われているとし、大手銀行・ヘルスケア・自動車などの採用を挙げています。

特徴は、ノーコードのアイデンティティオーケストレーション機能「PingOne DaVinci」です。ドラッグ&ドロップのFlow Studioで、複数ベンダーの認証・ID関連サービスを組み合わせたログインフローを構築できます。

リスクベース認証の「PingOne Protect」による不正検知にも対応し、OIDC・OAuth 2.0・SAML 2.0に加えWS-Federation/WS-TrustやFIDO2/WebAuthnまで幅広い規格をカバーします。

料金は公式ページ上で、PingOne for Customersが年額35,000ドル〜(Essential)、50,000ドル〜(Plus)と、一定規模の年間予算を前提とした水準です。実際の費用はアクティブユーザー数などに応じた個別見積もりとなります。

オンプレミス製品(PingFederateほか)と組み合わせたハイブリッド構成も選べ、国内ではNTTドコモビジネスが販売パートナーとして取り扱っています。

9. Uni-ID Libra（NRIセキュアテクノロジーズ株式会社）

企業のWebサービス・アプリで会員IDを統合管理し、認証やアクセス制御の基盤を構築するための国産パッケージ製品が、Uni-ID Libraです。NRIセキュアテクノロジーズ(野村総合研究所グループ)が自社開発する、BtoC向けの顧客ID統合・認証ソリューションです。

民間調査会社ITRの調査では、国内CIAM市場のベンダー別売上でシェアNo.1を9年連続(2016〜2024年度)で獲得したとされています。公式導入事例には、トヨタ自動車・近鉄グループホールディングス・TBSホールディングス・JCOMなど、大手企業のグループ共通ID基盤や会員IDプラットフォームでの採用が挙がります。大規模な会員基盤のID統合を想定した製品です。

認証方式はパスワード・ワンタイムパスワード・FIDO(パスキー)に対応し、SSOや同意管理(GDPR対応)、SCIM APIによるID管理、デジタル庁「デジタル認証アプリ」を用いたマイナンバーカード本人確認まで備えます。OpenID Connect・FIDOに加え、2026年7月提供版ではAPIセキュリティの国際規格FAPI 2.0の認定も取得しました。

オンプレミス・クラウドの両方式に対応し、要件定義の段階からNRIセキュアのID専門人材が支援します。料金は公開されておらず、個別の問い合わせが前提です。

特定機能をAPIで組み込むコンポーネント型(認可API・SMS/OTP認証)

フルスタックのCIAMではなく、認可サーバやSMS/OTPによる本人確認など、必要な機能だけをAPIで自社サービスに足したい場合に向くタイプです。

10. Vonage Verify（Vonage）

Vonage Verify は、グローバルCPaaS大手のVonage（Ericsson子会社）が提供する電話番号認証（2要素認証／OTP）APIです。電話番号を渡すだけで、SMS・音声（TTS）・WhatsApp・Email・サイレント認証といった複数チャネルへワンタイムコードの配信と検証を実装できます。ログイン画面まで含むCIAMではなく、本人確認の部分だけをAPIで足す部品型として使えます。

特徴は、端末のSIM情報をキャリアの記録と照合して番号を確認するサイレント認証に対応し、コード入力なしでの認証や、あるチャネルが届かない場合の別チャネルへの自動フェイルオーバーを設定できる点です。グローバルでの導入は12万社以上（Verify単体ではなくVonage全体の数値）とされ、海外・多言語ユーザーへの到達に強みがあります。

日本では、2024年2月14日より株式会社KDDIウェブコミュニケーションズが「Vonageコミュニケーションプラットフォーム(VCP)」として国内提供しており、日本語のカスタマーサポートと独自価格が用意されています。グローバル料金は認証成功ごとのプラットフォーム料金にチャネル送信料を加える従量課金で、国内提供価格は要問い合わせです。

11. Twilio Verify（Twilio）

SMS・音声・WhatsApp・メール・TOTP（認証アプリ）・プッシュ通知・パスキー・サイレントネットワーク認証（SNA）といった認証手段を単一のAPIにまとめたのが、Twilio Inc. の認証専用API「Twilio Verify」です。ワンタイムパスワードの生成・送信・検証を肩代わりし、トークン管理やレート制限を自前で実装せずに2要素認証・電話番号認証を組み込めます。

到達状況に応じたチャネル切り替えや、SMSポンピング詐欺への対策機能「Fraud Guard」を備え、検証メッセージの多言語自動翻訳（42言語）にも対応します。料金は認証成功1回につき$0.05〜（USD建て、チャネルごとの送信料が別途加算）で、ユーザー数ではなく認証成功単位で課金される仕組みです。

国内では、Twilioリセラーパートナーであるソフトバンク株式会社が2023年10月16日に取り扱いを開始し、日本語による24時間365日の保守・運用サポートを提供しています。日本法人のTwilio Japan合同会社もあり、海外ユーザーを多く抱えるサービスの認証基盤に向いています。

12. Authlete（株式会社Authlete）

Authlete は、2015年設立の日本発スタートアップ・株式会社Authleteが開発する「Authorization-as-a-Service」です。OAuth 2.0認可サーバーやOpenID Connect（OIDC）IDプロバイダーの実装に必要なプロトコル処理とトークンのライフサイクル管理を、バックエンドのWeb APIとして提供します。

Auth0やOktaのようなフルスタックCIAMと異なり、ログイン画面やユーザーデータベースは自社側に残したまま、認可サーバーのコアロジックだけをAPI化して外出しできるのが最大の違いです。認可・トークンのエンドポイントは自社アプリ側に実装し、その裏側でAuthleteのAPIを呼び出すため、既存の認証基盤を大きく作り変えずに標準準拠の認可サーバーを構築できます。

金融グレードAPI（FAPI）に対応し、2019年4月にOpenID Foundationの認定を取得、2025年7月にはFAPI 2.0 Security Profile Finalの世界初認定を公式発表しています。セブン＆アイ・ホールディングスの会員基盤「7iD」ではオンプレミス要件に合わせてセルフマネージド版が採用され、みんなの銀行のAPI認可基盤にも導入されました。

共用クラウド・専用クラウド・オンプレミスから選べ、料金はBusinessプランが月額118,000円（月間アクティブトークン数で課金）、Enterpriseは要問い合わせです。

パスワードレス認証導入の注意点・デメリット

導入効果が大きい一方で、事前に設計しておかないと利用者の離脱やサポート負担につながる論点があります。つまずきやすい3点を押さえておきましょう。

アカウント復旧・回復設計の落とし穴

パスキーは端末や資格情報マネージャに紐づくため、端末の紛失・故障・機種変更時にどう本人を確認して復旧させるかの設計が欠かせません。AppleのiCloudキーチェーンやMicrosoftのパスワードマネージャなど、クラウド同期で複数端末に引き継げる仕組みはありますが、それに依存しない利用者や、同期を無効化している利用者も想定する必要があります。

復旧手段を安易にSMSやメールだけにすると、そこがフィッシングの標的になり、せっかくのフィッシング耐性が損なわれます。復旧経路の強度まで含めて設計することが重要です。

出典・参考資料（1件）

• 参考資料：About the security of passkeys｜Apple（https://support.apple.com/en-us/102195）

OS・ブラウザのパスキー対応差への備え

パスキーはApple・Google・Microsoftの主要プラットフォームで対応が進んでいますが、利用者が使うOSやブラウザ、そのバージョンによって挙動や同期の範囲に差があります。自社サービスの利用者層が使う環境を洗い出し、パスキーに未対応・不慣れな利用者向けに、SMS/OTPやパスワードといった代替のログイン手段を残す段階的な設計が現実的です。

すべての利用者を一度にパスキーだけへ移行させると、対応環境の差で離脱を招くおそれがあります。

出典・参考資料（1件）

• 参考資料：The beginning of the end of the password｜Google（https://blog.google/technology/safety-security/the-beginning-of-the-end-of-the-password/）

ログイン離脱(カゴ落ち)を防ぐUX設計

認証はサービス利用の入口であり、ここでの手間や分かりにくさは利用者の離脱に直結します。パスキーの登録を促すタイミングや文言、うまくいかなかったときの案内、代替手段への切り替えのしやすさまで含めてUXを設計しないと、セキュリティを高めたつもりが利用率を下げる結果になりかねません。導入時はABテストや段階的な展開で、実際の登録率・成功率を見ながら調整する進め方が有効です。

パスワードレス認証導入の進め方

最後に、自社サービスへパスワードレス認証を導入する際の実務的な進め方を整理します。いきなり全面切り替えを狙うより、段階を踏むほうが失敗しにくくなります。

はじめに、対象とする利用シーン(会員ログイン・決済の承認など)と、必要な認証方式・想定ユーザー規模・満たすべきコンプライアンス要件を整理することから始めます。そのうえで自前実装か導入かを判断し、導入する場合は本記事の選び方の軸で候補を2〜3社に絞り込むことが重要です。

次に、絞り込んだサービスで小さく試す(PoC)ことをおすすめします。対応OS・ブラウザでの登録・ログインの挙動、既存の会員基盤との連携、復旧フローの使い勝手を実際のデータで確認しておくことが欠かせません。問題がなければ、まずは一部の利用者やパスワード併存から始め、登録率・成功率を見ながら対象を広げます。導入前に復旧・代替手段の運用ルールとサポート体制を固めておくと、本番展開後のつまずきを防げます。

まとめ

パスワードレス認証、とりわけパスキー/FIDO2は、公開鍵暗号と登録ドメインへの束縛によって、フィッシングやリスト型攻撃に強い認証を実現します。自社サービスのエンドユーザー向けに組み込むことで、不正ログインのリスクを下げつつ、ログイン体験を改善できます。

実装にあたっては、まず自前実装か認証SDK・API・CIAMの導入かを、工数・専門知識・料金・保守の観点で判断します。導入を選ぶ場合は、対応方式と提供形態、料金・課金モデル、日本語サポート、エンタープライズ要件という軸で、自社の用途に合うサービスを絞り込むとよいでしょう。

本記事の比較表と診断ツールを、自社に合う認証サービスを見極める材料としてご活用ください。気になるサービスがあれば、まずは資料を取り寄せて、機能・料金・サポート体制を具体的に確認することをおすすめします。

よくある質問(FAQ)

Q. パスワードレス認証とは何ですか？

A. パスワードレス認証とは、IDとパスワードの組み合わせに頼らず、生体情報や端末内に保存した鍵、ワンタイムコードなどを使って本人を確認するログイン方式の総称です。パスワードそのものを利用者に入力させないことで、使い回し・推測・漏えいといったパスワード起因のリスクを根本から減らせます。

近年の中心はパスキー(FIDO2/WebAuthn)で、端末のロック解除と同じ操作(生体認証・PIN)でサインインできます。自社サービスへ組み込む際は、パスキーを軸にSMS/OTPやソーシャルログインを併用する構成が一般的です。

Q. パスワードレス認証はなぜフィッシングや不正ログインに強いのですか？

A. パスキー/FIDO2がフィッシングに強いのは、秘密鍵がネットワークを流れず、鍵が登録したドメインにしか提示されないため、よく似た偽サイトに誘導されても端末が認証情報を渡さない仕組みだからです。SMSのワンタイムコードのように、利用者がコードを読み上げて盗まれる余地がありません。

ただし、フィッシング耐性が高いことと最高の保証水準を満たすことは別です。NISTのガイドライン(SP 800-63B-4)では、複数端末に同期される同期型パスキーは秘密鍵を持ち出せる性質があるため、最高保証水準であるAAL3の認証器としては用いないものとされています。「パスキーだから常に最高水準を満たす」と一律には言えない点は、社内説明時に押さえておくとよいでしょう。

Q. パスワードレス認証の導入に新しいハードウェアは必要ですか？

A. パスキーを使う場合は、多くのケースで専用ハードウェアは不要で、利用者が普段使うスマートフォンやPCの生体認証・PINでそのまま利用できます。より高い強度が必要な用途では、FIDO2セキュリティキーのような専用デバイスを併用する選択肢もありますが、一般的な会員サービスのログインでは必須ではありません。自社サービスの利用者に追加の機器購入を求めずに始められる点が、導入のハードルを下げます。

Q. 利用者がパスキーを登録した端末を紛失・機種変更した場合、どう復旧しますか？

A. 復旧手段をSMS・メールだけに頼らず、複数の経路を組み合わせて用意しておくのが基本です。具体的には、利用者に2台目以降のパスキーを平時から登録してもらう、発行時に一度だけ表示するバックアップコードを保管させる、AppleのiCloudキーチェーンやGoogleパスワードマネージャで複数端末に同期させる、といった備えが有効です。

紛失後の再登録では、本人確認を再度実行してから新しいパスキーを発行する設計にします。この復旧フローの設計・監視・保守は、認証SDK・API・CIAMを導入すればサービス側の機能として利用でき、復旧経路がフィッシングの標的になるのも防ぎやすくなります。

Q. パスキーはすべてのOS・ブラウザで使えますか？

A. すべての環境で同じようには使えないため、利用者層が使うOS・ブラウザとそのバージョンを洗い出し、対応状況で扱いを切り分けるのが現実的です。パスキーが安定して使える環境ではパスキーを既定にし、未対応・不慣れな層にはSMS/OTPやパスワードを代替として残します。

とくにブラウザ内蔵の資格情報マネージャと、OSやサードパーティのパスワードマネージャで同期範囲が異なる点に注意し、利用者が別端末でログインできなくなる状況を避けます。導入するサービスがどの環境まで検証済みかも、あわせて確認しておくと安心です。

Q. パスワードレス認証は、既存のパスワード認証と併存させながら段階的に導入できますか？

A. できます。おすすめは「パスワードとの併存 → 一部ユーザーへの先行提供 → 全体展開」と段階を踏む進め方です。まず既存のパスワード認証を残したままパスキーを任意で登録できるようにし、影響範囲を限定して挙動を確かめます。

次に、対応環境が整った一部の利用者やログイン方式に絞って先行提供し、登録率・成功率を計測します。問題がなければ対象を広げ、最終的に新規登録の既定をパスキーへ寄せていきます。既存の会員基盤との連携はPoCで先に確認しておくと、全体展開でつまずきにくくなります。

Q. パスワードレス認証は自前実装(FIDO2/WebAuthn)と認証SDK・API・CIAMの導入のどちらを選ぶべきですか？

A. 「認証を自社の差別化にしないなら導入、認証の細部まで自社で制御する明確な理由があるなら自前実装」が判断の軸です。多くのサービスでは、認証は差別化点ではなく確実に動くべき土台なので、導入が現実的な選択になりやすいです。

自前実装を選ぶなら、登録・認証フローだけでなく、機種変更時の復旧、OS・ブラウザ対応差、規格改定への追随、障害監視までを継続的に担える体制があるかで見極めます。決済・取引で金融グレードのAPI(FAPI)準拠が要る、既存パスワード基盤と長く併存させるといった要件があるほど、実装・保守の負担は導入寄りに傾きます。

Q. 認証SDK・API・CIAMの料金はどのように決まりますか？導入するとコストは増えますか？

A. 月間アクティブユーザー数(MAU)に応じた従量課金や、無料枠＋段階プランが主流です。試算では、平均ではなくピーク月のMAUで見積もるのが要点です。キャンペーンや季節要因でMAUが跳ねると、その月の課金も跳ねるためです。

あわせて、無料枠を超えた分に適用される単価と課金の刻み、上位プランへ切り替わる閾値を確認します。海外サービスは料金が米ドル・ユーロ建てのことが多く、為替変動で日本円の実額が動く点も織り込みます。オープンソースの自社構築は月額を抑えられる一方、構築・運用の人件費を加えて総額で比べます。

Q. 認証SDK・API・CIAMは、従業員向けの多要素認証(MFA)やIDaaSと何が違うのですか？

A. 守る対象が違います。CIAMは自社サービスにログインする顧客・会員のアカウントを、従業員向けMFA/IDaaSは社内システムやSaaSにログインする自社の従業員アカウントを守ります。目的が違えば、選ぶべき製品も変わります。

選定に効く違いとして、CIAMは不特定多数の会員を前提に、MAU課金・大量登録に耐える拡張性・登録離脱を抑えるUX・ソーシャルログインを重視します。従業員向けはユーザー数課金で、SSOやアクセス制御、退職者の権限剥奪(プロビジョニング)が中心です。会員認証の組み込みなら、従業員向け製品ではなくCIAMから検討します。

Q. 決済や取引の本人認証にもパスワードレス認証を使えますか？

A. 使えます。ただし決済・送金・取引の承認では、フィッシング耐性の高いパスキーに加え、金融グレードのAPI(FAPI)準拠や継続的な本人確認まで求められることがあります。会員ログインより一段高い確実性が要る領域です。

FAPIが必要になるのは、主に銀行・証券・決済などで第三者アプリへ口座情報や取引を安全に連携する(オープンバンキング／API連携)場面です。自社アプリ内で完結する会員ログインだけなら必須とは限りません。取引の承認そのものを強くしたい場合は、継続認証や取引ごとの再認証(ステップアップ認証)に対応するサービスが候補になります。

認証SDK・API・CIAMの料金・機能を一括チェック

MCB FinTechカタログでは、自社サービスに組み込める認証SDK・API・CIAMの最新資料をワンクリックで一括入手できます。気になるサービスの料金・機能・サポート体制をまとめて比較し、資料請求やオンライン相談の判断材料としてご活用ください。

MCB FinTechカタログに掲載しませんか？

MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。