SaaSプラットフォーム向け顔認証

ユーザー数が増えるほど認証にかかる運用負担も増えます。FACEIOの顔認証を追加して、パスワードへの依存を減らし、ユーザー単位のアクセス追跡性を高め、SaaSとWebアプリにおけるアカウント乗っ取りのリスクを抑えます。

FACEIO Consoleでアプリケーションを作成し、APIを管理し、登録、認証、Facial IDイベント用のWebhookを設定できます。

規模の拡大で生じるSaaS認証の課題

パスワード認証は、次のような運用上の問題を生みます。対象となるのは Software as a Service 製品です。これは、複数のサービスで認証情報を管理するようユーザーに求めることによる構造的な結果です。詳しくは パスワードレス認証の基礎 をご覧ください。

共有アカウントと追跡性の低下

追加のシート購入を避けるためにチームが1つのログインを共有したり、適切なプロビジョニングをせずに委託先へ認証情報を渡したりすると、追跡性が失われます。監査ログは意味を失い、アクセス制御は回避され、プラットフォームは実際の利用者を確実に把握できません。

パスワードリセットとサポートコスト

パスワード忘れは、Webアプリでよくあるサポート依頼の一つです。リセットのたびにサポートチームの時間が必要となり、ユーザー体験が中断されるほか、アカウント復旧フローにも適切なセキュリティ管理が必要です。

アカウント乗っ取り(ATO)とCredential Stuffing

大規模なユーザーベースを持つSaaSプラットフォームは、Credential Stuffing攻撃の主要な標的です。別のサービスから漏えいしたパスワードがログインエンドポイントに自動で試され、一致すると攻撃者はアカウントへアクセスし、データを持ち出したり、セッションを不正利用したりします。

共通する根本原因

これら3つの問題には、認証情報モデルという共通の根本原因があります。FACEIOを使えば、メインのログインフローからパスワードをなくし、サービス間で共有、漏えい、再利用されにくいブラウザベースの顔認証ステップに置き換えられます。

顔認証によってログインフローがどう変わるか

FACEIO の顔認証は、転送可能な秘密情報ではなく、ユーザーのライブ操作にアクセスを結び付けることで、これらの問題に対処します。認証モデルの一般的な概要については、認証を参照してください。

共有アカウントを使いにくくする

顔認証チェックでは、新しいキャプチャを登録済みの顔インデックスと照合します。パスワードとは異なり、認証要素はチャットで転送したり、認証情報の漏えいからコピーしたりできる再利用可能な文字列ではありません。

パスワードリセットの削減

FACEIOを主要なログイン方法として使うアカウントでは、通常の再訪問時に覚えておくパスワードがありません。パスワードリセットの問い合わせを減らし、サポートチームがより重要な課題に集中できます。

盗まれたパスワードだけではログインできない

Credential Stuffingは、盗まれた認証情報の組み合わせをログインエンドポイントで試します。FACEIOがパスワードの手順を置き換えると、漏えいしたパスワードだけでは認証できません。

これらの特性を支えるセキュリティアーキテクチャについては、開発者向けガイドとセキュリティのベストプラクティスを参照してください。

マルチテナント認証のパターン

多くのSaaSプラットフォームは、共有インフラストラクチャ上で複数の組織にサービスを提供します。FACEIOでは、プラットフォームのID管理方法に応じて、次の2つの方法でこの構成をサポートできます。

テナントごとのアプリケーション構成

各テナントに、個別の Public ID と分離されたインデックスを持つ FACEIO アプリケーションを割り当てます。登録された Facial ID と認証イベントは、そのテナントのアプリケーション内に限定されます。この管理方法については、トラストセンターを参照してください。

適した用途: テナントごとに異なるコンプライアンス要件があるプラットフォーム、または厳格なデータ分離が契約上求められるプラットフォーム。

テナントマッピングによる集中型ID管理

1つのFACEIOアプリケーションで全テナントの認証を処理します。登録時に関連付けるペイロードへテナント識別子と内部ユーザーIDを含めることで、バックエンドは返された Facial ID を正しいテナントのコンテキストに関連付けられます。

適した用途: テナントがコンプライアンス環境を共有し、生体認証インデックスではなくアプリケーション層で分離を行うプラットフォーム。

どちらのパターンも同じfio.jsメソッドを使用します。実装上の違いは、FACEIO Consoleの構成と、アプリケーションがenrollmentペイロードに含めるテナントデータです。

SaaSのユーザーフロー

FACEIOを使った一般的なSaaSのユーザーライフサイクルに、3つの主要な認証フローを適用する方法は次のとおりです。

1

サインアップと登録

アカウント作成時、ユーザーは標準のオンボーディングフォームに入力します。通常パスワードを設定する箇所で、アプリケーションは faceio.enroll() を呼び出します。ユーザーが短い顔撮影を行うと、FACEIOはアカウントに関連付けたFacial IDを生成します。登録時のペイロードには内部ユーザーIDとテナントメタデータを保存できます。この時点から、アカウントにパスワードは存在しません。

2

再訪問時のパスワードレスログイン

ユーザーがログインページを開くと、アプリケーションは faceio.authenticate()を呼び出します。ユーザーがカメラを見ると、FACEIOは設定された顔認識エンジンでライブ撮影を検証し、Facial IDを返します。バックエンドはそれをユーザーレコードに関連付けてセッショントークンを発行します。パスワードマネージャーの手順は不要です。

3

重要な操作のステップアップ認証

ユーザーが請求情報の変更、管理パネルへのアクセス、セキュリティ設定の変更など、重要な操作を行おうとすると、アプリケーションはトリガーを検知して authenticate() をもう一度呼び出します。バックエンドは返されたFacial IDを検証し、アクティブなセッションのIDと一致する場合だけ操作を許可します。通常のセッションには影響しません。

3 つのフローの実装手順は、統合ガイドを参照してください。実装を始めるには、FACEIO Consoleでアプリケーションを作成します。

運用面への効果

パスワード入力を置き換えることで、SaaSチームが追跡する複数の運用指標に影響する可能性があります。

サポートチケットの件数

顔認証に登録したユーザーでは、パスワードリセットとアカウント復旧のチケットが減ることが見込まれます。

セッション完了率

再訪問時のフローからパスワード入力をなくすことで、認証済みセッションの離脱につながる摩擦を減らせます。

ATOインシデント率

パスワード入力を顔認証に置き換えた場合、漏えいしたパスワードの組み合わせだけではそのログインフローを完了できません。

監査証跡の品質

認証イベントを共有認証情報ではなく、返されたFacial IDと内部ユーザーレコードに関連付けられます。

まとめ

共有アカウント、パスワードリセット、そして多くのアカウント乗っ取り経路は、認証情報モデルの結果です。FACEIOは、バックエンド認可、監査ログ、テナントマッピングを自社で管理しながら、SaaSチームがパスワード中心のログインから移行できるよう支援します。エンタープライズ向けの導入方法は、 マネージド顔認証サービス の選択肢と比較してください。

SaaSプラットフォームにFACEIOを追加する

FACEIOアプリケーションを作成し、インテグレーションガイドを確認して、登録、ログイン、ステップアップチェックをSaaSワークフローに組み込みます。

マルチテナント対応
ステップアップ認証
プライバシーを優先した管理