⇧ 破裂するのが前提というところが限界を感じますが、外部からの衝撃や裂傷なども想定して欲しいところですかね...
FIDO2（Fast Identity Online 2）とは？
公式のドキュメントによりますと、
ユーザー認証仕様の概要
FIDO アライアンスは、よりシンプルで強力なユーザー認証のための 3 つの仕様セットを発表している：FIDO Universal Second Factor (FIDO U2F), FIDO Universal Authentication Framework (FIDO UAF) and the Client to Authenticator Protocols (CTAP). CTAPは、その補完的なものである。 W3Cのウェブ認証（WebAuthn）仕様 これらは合わせてFIDO2と呼ばれている。
FIDO2
FIDO2 は、W3C ウェブ認証仕様と FIDO アライアンスの対応するクライアント認証プロトコル（CTAP）で構成される。 FIDO2は、組み込み（またはバインドされた）認証機能（バイオメトリクスやPINなど）または外部（またはローミング）認証機能（FIDOセキュリティキー、モバイルデバイス、ウェアラブルなど）によるパスワードレス、セカンドファクター、マルチファクターのユーザーエクスペリエンスをサポートしています。
⇧ とあるように、
- FIDO独自仕様
- FIDO U2F (FIDO Universal Second Factor)
- FIDO UAF (FIDO Universal Authentication Framework)
- CTAP (Client to Authenticator Protocols)
- 一般的なWebの仕様
- W3Cのウェブ認証（WebAuthn）仕様
⇧ 上記の4つの仕様で成り立っているのがFIDO2ということのよう。
何となく、
CISA、パスキーへの取り組みを称賛
イベントの最後を飾ったのは、米国土安全保障省（DHS）サイバーセキュリティ・インフラ安全保障局（CISA）サイバーセキュリティ担当エグゼクティブ・アシスタント・ディレクターのエリック・ゴールドスタイン氏による基調講演だった。
https://fidoalliance.org/recap-2024-identity-authentication-and-the-road-ahead-policy-forum/?lang=ja
ゴールドスタインは、課題がある一方で進展もあったことに注目することが重要だと強調した。 パスキーは現在、消費者が日常的に使用しており、パスワードレスの導入に移行する企業も増えている。
https://fidoalliance.org/recap-2024-identity-authentication-and-the-road-ahead-policy-forum/?lang=ja
「私たちは、より多くの企業が、企業権限、管理者権限、従業員認証ソリューションをパスワードレスへと移行しているのを目の当たりにしています。
https://fidoalliance.org/recap-2024-identity-authentication-and-the-road-ahead-policy-forum/?lang=ja
⇧「パスキー」推しな風潮ではありそう。
一応、
パスキーの年
Shikiar氏は、FIDOアライアンスはユーザー認証がIDバリューチェーンの1ピースに過ぎないことを理解していると指摘した。 そのため、FIDOアライアンスはパスキー以外にも、バイオメトリクスの認定プログラムや文書の真正性認定プログラムなど、複数の取り組みを行っている。
https://fidoalliance.org/recap-2024-identity-authentication-and-the-road-ahead-policy-forum/?lang=ja
⇧「バイオメトリクス（生体認証）」などにも取り組んでいるとのことですが、「パスキー」が強調されてる感はありますな。
何やら、Wikipediaの説明によると、
パスキー（英語: Passkeys）は、FIDO Allianceが策定したパスワードレス認証技術。パスワードに代えて生体情報を用いる。
実際に使用するためには、World Wide Web Consortium（W3C）と共同で定めた「FIDO2」「WebAuthn」「パスキー（狭義）」の3技術が必要であり、それらを合わせて「（広義の）パスキー」と称する。
技術概要
パスキー（広義）には、以下の3技術が用いられている。
- FIDO2：公開鍵暗号と生体認証を用いたパスワードレスの認証方式。スマートフォン等で生体認証を行ない、認証された後に秘密鍵によって暗号化した電子署名をサーバーへ送信。サーバーは受信した電子署名を公開鍵で検証し、問題ない場合はログイン等を許可する。生体情報自体は手元の端末（スマートフォン等）の中で閉じており、サーバーや外部ネットワークへ送信されることは無い。
- WebAuthn：FIDO2をWeb上で実現する仕様。FIDOが支援し、W3Cによって策定、標準化された。
- パスキー（狭義）：認証資格情報（マルチデバイス対応FIDO認証資格情報、Multi-Device FIDO Credentials）を、クラウド経由で同期する仕組み。
⇧ とあり、「パスキー（広義）」と「パスキー（狭義）」が紛らわしいですな...
「ダブル・ミーニング」をIT系の用語で行われるのは辛いところですな...
Wikipediaの情報が信頼に足るのであれば、「FIDO2」は、『「公開鍵認証」＋「バイオメトリクス（生体認証）」』という認証方法であることになるのですが、
FIDO2
FIDO2 は、W3C ウェブ認証仕様と FIDO アライアンスの対応するクライアント認証プロトコル（CTAP）で構成される。 FIDO2は、組み込み（またはバインドされた）認証機能（バイオメトリクスやPINなど）または外部（またはローミング）認証機能（FIDOセキュリティキー、モバイルデバイス、ウェアラブルなど）によるパスワードレス、セカンドファクター、マルチファクターのユーザーエクスペリエンスをサポートしています。
⇧ 公式の説明だと、「バイオメトリクス（生体認証）」以外にもサポートしているとあるので、Wikipediaの説明だと語弊を生むような気がする...
FIDO2（Fast Identity Online 2）の環境構築に必要な情報が分かり辛い
公式のドキュメントの説明だと、
Getting Started
For developers with existing web pages or applications that are looking to implement FIDO Authentication there are two changes that you will have to make to your application: 1) modifying the login and registration pages of your website or mobile application to use the FIDO protocols; and 2) setting up a FIDO server to authenticate any FIDO registration or authentication requests. The next two sections give a high-level overview of the steps to take for both of those changes.
⇧ 大きく分けて、
- 1) modifying the login and registration pages of your website or mobile application to use the FIDO protocols;
- 2) setting up a FIDO server to authenticate any FIDO registration or authentication requests.
とあるので、
- フロントエンド
- サーバーサイド
の両方で実装が必要になるっぽい。
で、マシンの観点で言うと、モバイルのNativeアプリケーションは一旦忘れて考えると、
- Webサーバー
- アプリケーションサーバー
- FIDOサーバー
の3つが登場してくるっぽいのだけど、
Adding a FIDO Server
There are far too many ways to integrate a FIDO server with existing authentication flows to cover them all comprehensively here.
For example, a FIDO server may be integrated with your web or application server, may be provided as a module within an existing IAM framework, may be a stand-alone server, or for very broad and complex services it may be any combination of the above. Also, FIDO may be integrated with an application-specific user data store (such as a MySQL or Mongo database), with LDAP / ActiveDirectory, provide SSO through an OpenID Connect (OIDC) identity provider (IDP), etc.
The wide variety of back-end authentication architectures and use cases makes it difficult to talk about all the details of FIDO server integration, so what follows are generic tips and considerations for FIDO server deployment. Specific server vendors and their documentation should add additional information about how to integrate FIDO into any pre-existing IAM environment.
⇧ FIDOサーバーについては、Webサーバーやアプリケーションサーバーと同じマシンに同梱させることもできたり、構成のパターンが何種類かあるということらしい。
で、最終的に、それぞれの役割のサーバーで、必要なライブラリなどの要件がサッパリ見えて来ない...
以下の説明（「Adding a FIDO Server」の段落に記載）が、また分かり辛いのだけど、
Aside from setting up the hardware and software for your server, there are several steps that are common across most server deployments:
- Servers will typically use REST endpoints to communicate with clients. This will require proper firewall configuration to communicate with clients. As mentioned previously, these endpoints may be part of existing applications (such as web servers or mobile application servers), or a micro-services architecture or ESB may be used to route messages to a stand-alone FIDO server.
- Servers require https communication, so they will need a valid TLS certificate for https (or, will require a TLS terminator in front of them).
- Servers may have policy configurations for determining when to allow registrations and authentications. For financial or government institutions, this may include use the FIDO Metadata Service (MDS) to validate the security of authenticators that are accessing services.
- Servers will need to integrate with some form of user data store (LDAP, ActiveDirectory, MySQL, MongoDB, etc.). For new services, this is simply a matter of having some kind of storage associated with each user’s account. For existing applications, this will require modifying data schema — typically adding some form of one-to-many relationship between user accounts and the authenticators / credentials that they will register.
⇧「Servers」は、「アプリケーションサーバー」のことを言っているということなんかな？
公式の別のドキュメントによると、
⇧ とあるので、FIDO Serverの役割としては、フロントエンドの秘密鍵に紐づく公開鍵を管理するってことなんかな？
アプリケーションサーバー側で、FIDO Serverで管理する公開鍵の登録、更新、参照などを担当するってことなのかな？
Javaについては、
⇧ OSSで「line-fido2-server」など、ライブラリを公開してくれているっぽい。
他の言語についてもGitHubでライブラリを公開してくれて入るっぽい。
「FIDO Server」は「アプリケーションサーバー」とは別マシンに用意しておくってことですかね？
クラウド環境とか利用しているなら、「FIDO Server」としては、マネージドなデータベースを利用していく感じですかね？
オンプレミス環境であれば、サーバーを用意してデータベースをインストールする感じになるのか。
サーバーサイド側では、最小構成としては、マシンが2台構成になっている必要はありそうですかね...
データベースとしては、「FIDO2」に利用する情報を管理する用のテーブルを分けておく感じにすれば良いんかな？
それとも、データベース自体を「FIDO2」用の情報を管理する専用のものを用意しておくべきなのか...
う～む、分からん...
フロントエンド側は、基本的には、サーバーサイド側で用意しておくAPIのエンドポイントにリクエストを飛ばすようにしてもらう感じになると。
いまいち、各サーバーでの機能の要件を満たすために必要なライブラリなどが分かり辛い...
そして、そもそも、FIDO2の秘密鍵・公開鍵が作成されるまでのフローが公式のドキュメントで触れられていないのだけど、
⇧ 上記サイト様のスライドのような感じで、フロントエンド側で「Authenticator」なるもので「認証」が通ることで、秘密鍵・公開鍵が生成されるということらしい。
後は、
⇧ 仕様書を頑張って読むしか無いんかな...
読む気が起きてこない...
毎度モヤモヤ感が半端ない...
今回はこのへんで。
