はじめに

最近パスキー(Passkeys)が話題です。

2023年は「パスキーの年」--FIDOアライアンスが報告 - ZDNET Japan

そして、Keycloakもサポートしています。
今日は、簡単にパスキーについてご紹介し、Keycloakの対応状況のご説明と、動作確認をしてみます。

パスキー(Passkeys)とは

パスキーはパスワードに変わる安全な「鍵」です。そしてパスキー認証とは、従来のID/パスワードを置き換える、安全かつ便利なログイン方式です。
パスワード認証には、「手間がかかる」「攻撃を受けやすい」といった課題がありますが、パスキー認証ではこれらを解決しています。

パスキー/WebAuthn/FIDO2など関連用語の定義

FIDOアライアンスがパスキーを発表したのは2022年5月であり、比較的新しいものですが、最近急速に盛り上がってきました。
一方これまで、パスワードレス認証として、「FIDO2」や「WebAuthn」という名前を聞いたことがある方もいるかと思います。これらとパスキーは何が違うのでしょうか。
まずは、関連用語の定義を確認したい思います。

名称	定義
WebAuthn	Webサイトがクライアント側にある認証器を用いた公開鍵認証をするための仕様と、そのためのブラウザ側のAPIのこと。
FIDO2	WebAuthnとCTAP21を包含する上位仕様
パスキー	「パスワードレスFIDOクレデンシャル」のこと。つまり、FIDO2/WebAuthn2のログイン対象ごとの秘密鍵・公開鍵ペアのことである。これまでのパスワードと同列であり、それを置き換えるものである。言い換えると、WebサイトごとにIDとパスワードがあったように、Webサイトごとに「パスキー」があるイメージ。
同期パスキー	プラットフォーム(クラウド)経由で同期するパスキー。
デバイスバウンドパスキー	認証器に固定されている、同期しないパスキー。

なお、上記は2023年12月時点でのFIDOアラインスの定義に基づきます。これらの用語はこれまで定義が変化してきたり、FIDOアライアンスの定義が業界のコンセンサスを得ていないケースで意味の揺れがあったりすることもありました。

同期するもののみを指すケース

パスキーはFIDOアライアンスの発表では、「マルチデバイスFIDOクレデンシャル」の通称という扱いでした³⁴。つまり、当初はクラウド同期して複数デバイスで使えるもののみがパスキーでした。しかし、パスキーの勢いを見てか分かりませんが、セキュリティキーベンダーが自分たちもパスキーだと主張し始めました⁵。その後FIDOアライアンスもSingle-device passkey(現: デバイスバウンドパスキー)を定義し、同期しない従来のFIDOクレデンシャルもパスキーとなりました⁶。

認証方式を指すケース

パスキーは「FIDOクレデンシャル」ですが、パスキー登場時の各種記事で「パスワードを使わない認証機能『パスキー』を発表」のように紹介(誤解?)されたためか、認証方式だという認識も広まりました⁷⁸⁹。

恥ずかしながら、私もこの記事を書くまでは認証方式のことだと誤解しておりました。しかし記事を書くに当たってFIDOアライアンスのパスキーのサイトやpasskeys.devの用語集を確認した結果、認識を改めるに至りました。

パスキーとは まとめ

ここまでをまとめると、パスキーとは、以下のように捉えていただくと良いかと思います。

パスキーがなぜパスワードの課題を解決するのか

ここまでパスキーについてご説明してきましたが、ではなぜパスキーはパスワードの課題を解決するのでしょうか？
根本的には、共通鍵認証と公開鍵認証の違いと、認証仕様の標準化です。

パスワードはユーザーとサービスで共通の「パスワード」を共有することで、ユーザー認証を行います。パスワードを知っているのだからユーザーAさんに間違いない、という仕組みです。これは共通鍵による認証です。

また、パスワードは人間が記憶をもとに手動で入力することが出発点のため、その共通鍵の安全性はユーザーの心がけに依存しています。ここから、「簡単なパスワードを使う」「複数サイトで使い回す」「フィッシング詐欺に遭う」「覚えられない」といった課題が生じます。
この課題はパスワードマネージャーである程度解決は可能ですが、一般の方が使いこなすのは難しい面もあります。

パスキーは、ユーザー側に秘密鍵を置く公開鍵認証で、かつその仕様をWebAuthnで標準化しています。ユーザーが難しい操作を行うことなく、自動で公開鍵認証を済ませてWebサイトにログインできます。共通鍵がネットワークを流れることもなく安全であり、パスワードの課題の多くを解決しています。

Keycloakのサポート状況

パスキーについては理解できましたが、Keycloakの対応状況はどうなのでしょうか？

Keycloakは2023年11月にリリースされたバージョン23より、パスキーをプレビュー扱いでサポートしていると明言されています。
Keycloak 23.0.0 リリースノートに、Passkeys supportとして記載されています。
ただしこの文章をよく見ると、

Passkey registration and authentication are realized by the features of WebAuthn. Therefore, users of Keycloak can do passkey registration and authentication by existing WebAuthn registration and authentication.

パスキーの登録と認証はWebAuthnの機能なので、既存のWebAuthn機能でパスキーも対応していると言っているようです。またバージョン23でパスキー向けに特別に何か実装がなされたわけでもないため、このリリースノートは単に対応していることの明言に過ぎないように見えます。
なおWebAuthnはKeycloak 8より対応しています。

Keycloakでの動作確認

それでは実際にKeycloakでパスキー認証を設定し、動作を確認してみましょう。当記事では次のバージョンを前提とします。

Keycloak: 23.0.1

事前準備

Keycloakを適当な環境で起動し、管理ユーザを作成します。なお当記事ではWebAuthnを扱うため、ブラウザに入力するURLのホスト名がlocalhostでない場合は、HTTPSが必須であり、その証明書も不正な証明書を一時的に許可した状態ではWebAuthnが使えないことがあります(Windows上のChromeとEdgeで確認)。
私はこの記事のため、Amazon EC2の1インスタンスにてKeycloakを起動し、Cloudflareに独自ドメインを設定してHTTPSに対応しました。

Keycloakの設定

Keycloak管理コンソールへアクセスします。
そして、適当にmasterレルムとは別にレルムを1個、realm1という名前で作成し、そこで作業します。

WebAuthn Passwordless Policyの設定

左側のメニューの「Authentication」をクリックし、「Policies」タブをクリックし、「Webauthn Passwordless Policy」をクリックします。以下のような表示がされると思います。

以下のように設定し、「Save」をクリックします。

• Signature algorithms: RS256を追加(Windowsのバージョンによってはこれにしか対応していないため)
• Require resident key: Yesに設定(ユーザ名入力なしにWebAuthnでログインしたいため)
• User verification requirement: Preferredに設定(Not specifiedのままだと、ログイン時に正常に動作しないため、おそらくKeycloakのバグ)

認証フローの設定

Built-inと表示されているbrowserフローの一番右のメニューをクリックし、「Duplicate」をクリックします。

Nameにお好きな名前、例えば「Passkeys」と入力し、「Duplicate」をクリックします。

このような表示がされると思います。
「Cookie」以外はゴミ箱アイコンをクリックし、削除します。

全体の「Add sub-flow」をクリックし、「Name」に「Form Auth」を設定します。Requirementを「Alternative」に設定します。
「Form Auth」の追加アイコン(+アイコン)をクリックし、「Add Step」をクリックします。「Username Password Form」を追加します。
全体の「Add step」をクリックし、「WebAuthn Passwordless Authenticator」を追加し、Requirementを「Alternative」に設定します。

フローが上記の表示の通りになったら、右上の「Action」メニューから「Bind flow」をクリックします。

「Browser flow」が選択されていることを確認し、「Save」をクリックします。これで、今回作成した「Passkeys」認証フローがブラウザでのログインに適用されるようになりました。

「WebAuthn Passwordless」と「WebAuthn」

WebAuthn Passwordless Authenticatorの隣には、WebAuthn Authenticatorがあります。この2つは以下のように使い分けます。

• WebAuthn Authenticator: 多要素認証における二要素目以降の認証用に使う。例えば、ワンタイムパスワードの代わりとする。
• WebAuthn Passwordless Authenticator: 最初の認証要素として使う。つまり、ID/ぱすわーど認証の代わりとして使う。そのため、パスワードレス認証と呼ばれる。

ユーザの追加

左のメニューの「Users」から、適当に一般ユーザ1名を追加します。
「Credentials」からパスワードを設定し、「Temporary」はOffにします。
このユーザを用いて後でログインを行います。

ログイン動作の確認

認証フローの確認(パスキー登録前)とアカウントコンソールへのログイン

適当なブラウザで https://(ホスト名)/realms/realm1/account/にアクセスします。 (httpでlocalhostの場合は適宜読み替えてください)
今回は、アプリケーションは用意せず、表示されたこのKeycloakの一般ユーザ向けアカウント管理アプリを使います。

右上の「Sign in」をクリックします。

ここで「Try Another Way」をクリックします。

認証フローで設定したとおり、ユーザー名+パスワードによるログインと、WebAuthnによるログインの選択式となっている事が分かります。ここで「Security Key」をクリックすると、次のような表示になります。

「Sign in with Security Key」をクリックすると、あなたの端末環境のパスキーで認証を試みます。ただしまだパスキーをKeycloakに登録していないため、何をしても認証に失敗します。
ここはいったん「Try Another Way」をクリックし、今度は「Username and Password」をクリックします。

ユーザ名+パスワードの入力フォームに戻るので、ユーザーを作成した際のユーザ名とパスワードでログインします。

このように、アカウントコンソールへログインが完了します。

パスキーの登録

ここまでで、あなたは一般ユーザでアカウントコンソールへログインしました。次回のログインからパスワードではなくパスキーでログインしたいとします。その場合、Keycloakにパスキーを登録します。
左側の「Personal info」をクリックします。左側のメニューを表示します。

「Account security」の中の「Signing in」をクリックします。

ここではユーザーの各種認証用クレデンシャル(パスワード、ワンタイムパスワードアプリの登録、パスキー)をユーザー自身で登録・変更することができます。パスキーを登録するには、「Passwordless」の中の「Set up Security key」をクリックします。
(Keycloakは全体的にパスキーではなく「Security key」という言葉を使っています)

ここでは「Register」をクリックします。

Windows 11 23H2 上のChrome/Edge/Firefoxの場合はこのようなダイアログが出ます。
ここの挙動は、環境(主にOSに依存)によって異なります。
このパソコンはPIN認証を設定しているため、PINを入力します。すると、

このようなダイアログになりました。
ユーザー名userの表示が重要です。つまりこのパスキーは、ユーザーIDを含んでいます。パスキーにはユーザーIDを含むものと含まないものがあり、含むものは「Discoverable Credentials」(旧名: Resident Keys)と呼び、ログイン時の利便性が向上します。この記事ではポリシーの設定でResident Keyを強制しています。

なお、Windowsではパスキーは同期されません(さきほどのダイアログでも「このデバイスにパスキーを保存して」と説明がありました)

参考までに、Android14のChromeの場合はこのような表示になりました。これはGoogleのアカウントが表示されている(モザイクかけました)ため、Googleアカウントに同期されるパスキーです。

パスキーの登録が完了するとこのように表示されます。
この状態でログインしてみましょう。
いったん、アカウントコンソール右上にある「Sign out」ボタンをクリックしてログアウトします。

パスキーによるログイン

ログアウトした状態で、再度https://(ホスト名)/realms/realm1/account/にアクセスします。最初にログインしたときと同様、ユーザー名とパスワードの入力欄の下にある「Try Another Way」をクリックし、次の表示で「Security Key」をクリックします。

この表示で「Sign in with Security Key」をクリックすると、

WindowsのChromeであればこのように表示され、パスキーを選択できます。
いずれか1個のパスキーを選択すると、Windows Helloのダイアログが出現します。

この場合はPINを入れると、

無事にログインが完了しました。

今後の改善について

Keycloakでは、ご覧の通りパスキー認証が十分利用可能なことが分かりました。
ただ、私は以下のように、UIの改善余地もあるかなと思いました。

「Security Key」

「Security Key」という表記は、YubikeyのようなUSB接続のセキュリティキーしか対応していないような印象になるため、パスキーに表記を変更するべきと思います。
というわけで、GitHubのディスカッションに提案を投稿してみました。

無駄な画面遷移

今回設定した認証フローでは、画面遷移に無駄が多くなっています。認証方法の選択が必要だったり、ボタンを押す以外ないのにわざわざ押させたり。

例えば、GitHubのように、ID/パスワードの入力フォームの下に「パスキーでログイン」ボタンを設ければ、スムーズにいけると思います。あるいは、WebAuthn Conditional UIに対応し、ユーザIDの入力時にパスキーが補完されるようにする、ということも考えられます。

この問題は、Keycloakは認証方式をそれぞれAuthenticatorとして実装し、それを認証フローとして管理者が自由に組み立てられることに起因しています。

KeycloakのGitHubリポジトリでも、改善が議論されています。例えば、弊社メンバーが開始した以下のディスカッションが盛り上がっています。

今後に期待したいですが、すぐにKeycloakでパスキーを使いたい場合は、UIテンプレートのカスタマイズである程度は対応可能です。

最後に

パスキー対応サイトは、特に2023年、急速に増えました。
FIDO2/WebAuthnは今となって思えばとっつきにくい印象があったのは確かです。認証関連に詳しいエンジニアの中で知る人ぞ知る技術であり、世の中への展開はなかなか進みませんでした。それがパスキーによって一気に空気が変わりました。

みなさまも、ご自身のアプリケーションをパスキーに対応してみてはいかがでしょうか。Keycloakを用いれば、この記事の通り簡単に対応可能です。

NRIでは、Keycloak by OpenStandia Advent Calendar 2023にて、Keycloakをインストール方法からご紹介しています。是非他の記事もご覧ください。

1. Client to Authenticator Protocol2。USB、NFC、またはBLEを介したFIDO2対応ブラウザーおよびオペレーティングシステムでの認証に外部認証システム（FIDOセキュリティーキー、モバイルデバイス）を使用するためのプロトコル。← FIDOアライアンスのWebサイトの「仕様概要」(2023年12月10日 (日) 10:05 UTC閲覧) の一部を筆者が要約。 ↩

2. 厳密にはFIDO2に限らず、FIDO UAFの秘密鍵・公開鍵ペアも指す模様。 ↩

3. パスワードレス認証の普及を加速させる取り組み ↩

4. Apple、Google、MicrosoftがFIDO標準のサポート拡大にコミット、パスワードレス認証の普及を促進 ↩

5. YubiKeys, passkeys and the future of modern authenticationでパスキーの定義は「any WebAuthn/FIDO credentials」と発信。 ↩

6. 遅くとも2022年8月時点で、Single-device passkeyという言葉が公式サイトに存在している。 ↩

7. iPhoneの新機能「パスキー」のセキュリティはどうなってる？ - ケータイ Watch ↩

8. Passkeys（パスキー）って結局なんなの？ パスワードの｢怖さ｣や｢面倒臭さ｣を解消する機能です ↩

9. Apple・Google・Microsoftがパスワードなしの認証システム「パスキー」の利用拡大に合意 - GIGAZINE ↩

10. 先にFIDO2/WebAuthnが策定され、後からその鍵をパスキーと呼ぶことにしたという経緯から違和感があるかもしれませんが、わかりやすさを優先しています。また、FIDO2とWebAuthnは異なるものですが、あなたがWebAuthnやCTAP2を直接実装するような開発者でなければ、問題ないと思います。 ↩