既存のウェブページやアプリケーションをお持ちの開発者がFIDO認証を実装するには、アプリケーションに2つの変更を加える必要があります: 1) FIDOプロトコルを使用するために、ウェブサイトまたはモバイルアプリケーションのログインおよび登録ページを修正する。 2) FIDO登録または認証要求を認証するためのFIDOサーバーの設定。 次の2つのセクションでは、この2つの変更に必要なステップの概要を説明する。

登録とログインの変更

アプリケーションにアカウントの登録とログイン機能がすでにあると仮定すると、FIDO認証を追加するのは、登録画面とログイン画面を修正するのと同じくらい簡単です。

最初に決断しなければならないのは、FIDOを第一要素認証(パスワードレス)に使うか、第二要素認証に使うか、ということだ。 その決定には、ここでは説明しきれないほど多くの考慮事項(使いやすさ、プラットフォームの可用性、アプリケーションの種類、リスク許容度など)があるが、良いニュースは、第一要因にFIDOを使うか第二要因にFIDOを使うかにかかわらず、実装はほぼ同じに見えるということだ。

参加登録

FIDOを登録ウェブページに統合するのは、適切な登録APIコールを呼び出すだけで簡単です。 各FIDO仕様の登録コールは以下の通り:

  • uaf: uaf_operation (
    iOS
    ,
    Android
    ) – UAFクライアントAPI仕様は、UAF_OPERATIONの操作タイプを持つAndroid IntentとiOS x-callbackスキーム(それぞれ)を定義している。
  • U2F:
    register()
    – U2F仕様は、ブラウザで登録を実行するためのJavaScript APIを定義している。
  • FIDO2 / WebAuthn:
    navigator.credentials.create()
    – WebAuthn 仕様 (FIDO2 プロジェクトの一部) は、ブラウザで新しいクレデンシャルを作成 (登録) するための navigator.credentials.create() API を定義しています。

これらのAPIコールはそれぞれ、アプリケーションがサーバーからチャレンジ(大きな乱数)をフェッチし、それを対応するAPIコールに渡すことを要求する。 サーバは、オーセンティケータに送られたチャレンジと、オーセンティケータから返されたチャレンジが一致することを確認します。そのため、アプリケーションは、チャレンジとユーザ名/ユーザアカウントを追跡するために、何らかのセッション管理(例えばクッキー)が必要になるでしょう。 APIコールを行った後、APIコールの結果のJSONメッセージがサーバーに送り返され(通常、サーバーによって定義されるRESTエンドポイントを介して)、サーバーは登録メッセージのチャレンジ、署名、オリジン、およびその他の主要なセキュリティ特性を検証する。 各FIDO仕様には、サーバーがメッセージを検証するために実行しなければならない検証の記述がある:

サーバーは、登録が成功したか失敗したかに応じて、成功または失敗で応答する。

各ユーザーのアカウントには複数の認証機能が登録されている可能性があるため、UXフローでは、ユーザーが複数の認証機能を追加したり、認証機能を区別するための名前を付けたり、認証機能を削除(紛失や盗難の場合など)したりできるようにする必要があります。

ログイン

FIDOを使ったログインは、登録とよく似ている。 FIDO仕様ごとに登録呼び出しがあるように、同様のログインAPIがある:

  • uaf: uaf_operation (
    iOS
    ,
    Android
    ) – UAF Client API仕様は、UAF_OPERATIONの操作タイプを持つAndroid IntentとiOS x-callbackスキーム(それぞれ)を定義している。
  • U2F:
    sign()
    – U2F 仕様は、ブラウザでアサーション(ログインなど)に署名するための JavaScript API を定義している。
  • WebAuthn:
    navigator.credentials.get()
    – WebAuthn 仕様では、ブラウザ経由でクレデンシャル (ログイン) を使用するための navigator.credentials.get() API を定義しています。

ここでも、登録コールと同様に、ログインAPIコールはサーバーからのチャレンジを必要とする。 例えば、WebAuthnは、以前に登録されたアカウントの「クレデンシャルID」を必要とするかもしれません。 APIコールにチャレンジを渡し、JSONをサーバーに返し、サーバーからの成功/失敗のレスポンスを待つ。

FIDOサーバーの追加

FIDOサーバーを既存の認証フローと統合する方法は、ここでは網羅しきれないほどたくさんある。 例えば、FIDOサーバーは、ウェブサーバーやアプリケーションサーバーと統合されることもあれば、既存のIAMフレームワーク内のモジュールとして提供されることもあれば、スタンドアロンサーバーであることもあり、非常に広範で複雑なサービスの場合は、上記のいずれかの組み合わせとなることもある。 また、FIDOはアプリケーション固有のユーザーデータストア(MySQLやMongoデータベースなど)やLDAP/ActiveDirectoryと統合したり、OpenID Connect(OIDC)IDプロバイダー(IDP)を通じてSSOを提供したりすることもできる。 バックエンド認証のアーキテクチャやユースケースは多種多様であるため、FIDO サーバー統合のすべての詳細について話すことは難しい。 特定のサーバーベンダーとそのドキュメントは、既存のIAM環境にFIDOを統合する方法に関する追加情報を追加する必要がある。

サーバーのハードウェアとソフトウェアのセットアップ以外にも、ほとんどのサーバー導入に共通するステップがいくつかあります:

  • サーバーは通常、クライアントと通信するためにRESTエンドポイントを使用する。 そのためには、クライアントと通信するための適切なファイアウォール設定が必要になる。 前述したように、これらのエンドポイントは既存のアプリケーション(ウェブサーバーやモバイルアプリケーションサーバーなど)の一部である場合もあれば、マイクロサービスアーキテクチャやESBを使用してスタンドアロンのFIDOサーバーにメッセージをルーティングする場合もある。
  • サーバーは https での通信を必要とするため、https 用の有効な TLS 証明書が必要になる(または、その前に TLS ターミネータが必要になる)。
  • サーバーは、いつ登録と認証を許可するかを決定するためのポリシー設定を持つことができる。 金融機関や政府機関では、サービスにアクセスする認証者のセキュリティを検証するためにFIDOメタデータサービス(MDS)を使用することも含まれる。
  • サーバーは、何らかのユーザーデータストア(LDAP、ActiveDirectory、MySQL、MongoDBなど)と統合する必要がある。 新しいサービスの場合、これは単に、各ユーザーのアカウントに何らかのストレージを関連付けるだけの問題である。 既存のアプリケーションの場合、これはデータスキーマを修正する必要があり、典型的には、ユーザアカウントと、ユーザが登録する認証子/クレデンシャルの間に、何らかの形で一対多の関係を追加する。

FIDOサーバーのアーキテクチャと設定に関するその他のフォーラムは、以下をご覧ください。 こちら [地域資源ページへのリンク].