macOS向けFirefox(122.0.x)におけるPasskey Autofillの挙動を確認した

こんばんは ritouです。

Firefix の Passkey Autofill 対応

MacOSではFirefox 122.0からiCloud Keychainへの保存と利用が可能になったようです。

www.mozilla.org

Firefox now supports creating and using passkeys stored in the iCloud Keychain on macOS.

ついでに Autofill もサポートしたとか。ブラボー!

早速見てみました。

挙動を確認

この動作確認時の自分の環境のバージョンは

です。

まずは何もパスキーがない状態の挙動を見てみましょう。

Autofillが作動して、なんか出てきました。

iCloud Keychainに保存されていないのでこんなもんか、ここクリックしたらHybrid/SecurityKeyあたりの挙動になるんだろという感じです。

Chrome, SafariQRコードが出てきますが、別の端末のパスキーを使えそうというのがわかったのでおkでしょう。

では1つ登録してみます。

デフォルトだとiCloud Keychainに保存するよとなります。

この状態からAutofillはどうなるでしょうか?

画像撮りなおしたのですが、未登録の時と一緒ですね。サジェストされてこない。

ここで "Passkeyを使用する" を押すとどうなるでしょうか。

iCloud Keychainには保存されているので、出てきます。

なるほどねと。Autofillとは何だったのか という感じになりつつ続けます。

次はもう一個パスキーを登録します。

この時にAutofillの挙動がどうなるかを確認しましょう。

わかってはいましたが、最初の画面は一緒です。"Passkeyを使用する" を押すとどうなるでしょうか。

ここで2つ出てくるわけですね。なるほど。

Autofill使わない、かつユーザー名を入れずに "Authenticate" を押した時と一緒なのでは?と思いました。やってみます。

画像省略です。一緒でした。

まとめ

ということで、現時点のmacOS向けFirefoxのAutofillの挙動 をまとめると

  • Autofill で表示されるのは "Passkeyを使用する" / "パスワードを管理" っていうリンクっていうかボタンだけ
  • 挙動は One Button パターンとか自分が呼んでいたものと一緒

という感じです。

Autofillによって、パスワードの候補と同様のUIとしてパスキーも扱えると思っているとちょっと残念な感じですね。マネフォの人に怒られるぞ

なんとかフォローしようと思うと、MIXI MのようにAutofillのみに対応しているサービスでもパスキーでログインボタンを探しちゃう皆さんにとって、フォームにフォーカス当てるだけでリンクが出てきてわかりやすい人もいるかもしれないぐらいでしょうか?

これが...

こう!

(幅が絶妙で下のログインボタンと一体化してしまったな!)

Windows向けはまた挙動が違うみたいですし、今後改善されることを期待しましょう。

ではまた。

"OpenID Connectは認可のための仕組みであるOAuth 2.0を認証のために拡張したもの" という表現が気になったが実は...

ritouです。

あることがきっかけで、これが気になりました。

この表現、検索するとたくさん出てくるんです。

  • 仕様策定の時期
  • OIDC Core 1.0にある "OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol." という記述の解釈

というあたりからこのような表現になっているのでしょう。

ただ、この前提でプロトコル自体を解説、理解しようとすると何かうまくいかないところがあるのではないでしょうか? と思うところがあります。

特にUserInfo Endpointのあたりについて、

  • これまでOAuth 2.0でプロフィールAPIを実装したら認証に使えたけど実装がバラバラだった(不便なOAuth認証)
  • OIDCではそのレスポンスなどを標準化したんだ!

みたいな説明がされていたりします。何を想像して勝手に経緯を補完しているのだと。 これは言ってしまえばただのOAuth認証の標準化であり、OIDCの方針とは異なります。

ritou.hatenablog.com

実際、このような流れでは仕様策定が行われていないのです。

  • OAuthは利用環境や技術スタックの変化に伴い、リソースアクセスのための仕組みとして1.0 -> WRAP(2.0の初期Draft的な立ち位置) -> 2.0と進化してきた
  • OpenIDも同様の変化を意識しつつ、認証イベントのやり取りのためにOpenID 2.0 -> OpenID Connect と仕様策定が進められてきた
  • 同時期に存在することになったOAuth 1.0とOpenID 2.0を同時に使用するための拡張仕様が策定されたこともあるが、別路線で進んでいた
  • OpenID Connectでは認証イベントのやり取り(IDTokenのあたり)に加え、UserInfo Endpointから非同期/継続的に最新のユーザー情報を取得するという要件があり、この部分が機能的にOAuthと重なる部分である
  • OpenID ConnectのJSON、RESTなどを使うという設計方針と、OAuth WRAPあたりが一致していたため、別々に策定を進めるのではなく「OAuth 2.0の上にIdentityレイヤを乗せる形」として最適化を進めるべく合流した

というのが実際に行われたことです。

この辺りの流れは先日行われたOpenID Summit Tokyo 2024に合わせてNatさんが公開した動画で触れられています。

www.youtube.com

この辺りを意識してもらうと、OIDC/OAuth 2.0のプロトコルを理解しやすくなるかもなーというところでした。

で、心の中で「誰が広めたんや😤」と思っていたわけですが、どうやら自分もその中の一人のようでした。

呪術廻戦 249話 乙骨先輩ばりの展開です。領域展開して踏ん張っていきましょう。この後、退場してしまう気もする

ではまた。

まだはやい 効率的なパスキー管理 - 2023年12月版

ritouです。

この記事はDigital Identity技術勉強会 #iddance Advent Calendar 2023 シリーズ2の記事です。

qiita.com

パスキー管理についてのお話です。

現状

プラットフォーム、OS、ブラウザ、パスワードマネージャーアプリ、アプリケーション全てのレイヤーで一気に対応が進められているパスキーですが、意識を高めて使っていこうと思った時の悩みとして、 どうやってパスキーを管理していくのが安全で便利なんだろう というのがあります。

Apple, Google, MSがパスキーやっていきな声明を出した頃、世の中のほとんどの人がサービス毎に一つだけ パスキーを登録(作成)すればクロスプラットフォームで使えるんや!最高だな!となり、その後の状況を知るとサクッと絶望した人もいるでしょう。世の中そんなものです。

この記事では、よく言われている管理方法と悩みどころについてざっくり整理します。

前提

現状では、パスキーを管理する仕組みとして以下のものがあります。

  • プラットフォームアカウントに紐づけられるパスワードマネージャー: iCloud キーチェーン、Googleパスワードマネージャー(on Android)
  • パスワードマネージャーアプリ: 1Passwordなど
  • セキュリティキー: YubiKey, Titan Security Key

MSも同期がんばれ。と言うことで、まずは、この中でどれを使ったら一番シンプルになるのかなと考える人が多いでしょう。

パスキー管理を一箇所でなんとかできないか

とにかく管理をシンプルにしたい勢の案はこんな感じでしょう。

  • 私はApple端末のみを利用します。別プラットフォームを使うときはiPhoneQRコードを読み込んでなんとかします
  • 私は1Passwordのクロスプラットフォーム対応に賭けます
  • コンシューマー向けサービスでもセキュリティキーを使います

シンプルに管理するということは、単一のパスキーでどこまでいけるか、あとはその管理が第3者に奪われた時にどうするか?が重要になります。 プラットフォームアカウントやパスワードマネージャーアプリのアカウントを⚪︎ぬ気で守る必要がありますし、セキュリティキーで保存できるClient-Discoverable Credentialsには上限がある上に無くしたり壊したりしてはいけない、そしてコンシューマー向けサービスだとセキュリティキー使えないところあるじゃんみたいなところが悩ましいところでしょう。

さいきょうのパスキー管理を目指すぐらい意識が高まっているので、次はその重要なアカウントをパスキーで守ればいいじゃないとなるかもしれません。

一箇所で管理しているパスキーの束をセキュリティキーで守ってみたらどうか

  • AppleGoogleアカウントをセキュリティキーで守るんよ
  • 1Passwordのアカウントもβでなんやかんややってると聞いた

こんな感じで、 パスキー対応サービスのパスキーn個を1個のアカウントに集約し、それをセキュリティキーで守るみたいなやり方がありそうです。

ご存知の通り、Googleアカウントはパスキーとしてセキュリティキーを設定することは、できます。

Appleの場合は2FAですが、セキュリティキーを利用できます。ただし、2個必要でそのうち1個は鍵付きの引き出しにしまっておくんですよ。🐈との約束!

先ほど、こんなこと書きました。

セキュリティキーで保存できるClient-Discoverable Credentialsには上限がある

コンシューマー向けサービスだとセキュリティキー使えないところあるじゃん

いくらTitan Security Keyでたくさん保存できるようになったといえども、普段使いのサービス、これからも増えるとなると保存しきれなくなる気がしますが、重要なアカウントの保護に利用するために使うのは割と適切に見えますね。

これで何となく安全そうですが、

  • プラットフォームアカウント自体のBANとかのリスクもあるよね
  • (これまでの流れを全否定してる気もするが)1箇所で管理するって方法はどうしても利便性悪そう

みたいなところがあります。

となると、単一は諦め、かつそのプラットフォームごとにパスキーがすんなり使えるような状況にしつつ最後にセキュリティキーで守ったらええやんという考えになりそうです。

サービスのパスキーは2箇所とかで冗長化、かつそのアカウントはセキュリティキーで守ってみたらどうか

パスキーを管理するプラットフォームアカウントなんて数が知れているので、そいつらをセキュリティキーで守ってやりつつ、利用しているプラットフォームごとにパスキーは作っておく、どっかのアカウントがおかしくなることも考えてパスキー対応サービスでは2個ぐらいパスキーを登録しておくと言う感じですね。

現状で言うと、安全で便利な感じのパスキー管理としてはこれぐらいかなーと思います。

今後

  • パスワードマネージャーからのエクスポート/インポートができるようになる
  • Windowsでもパスキーが同期できるようになる
  • Googleアカウントに紐付けられたパスキーがPCでも...

みたいなことが進むと、単一のパスキー管理で十分いける状態になるのかもしれません、というかそうなって欲しいですね。

まとめ

何となく想像しているであろうパスキー管理の方法、そして悩みどころを書いてみました。

自分はこう思う、みたいなのがあったらXやはてブで反応いただけるとありがたいです。

2023年12月の時点ではこんなんだったけど、来年末にどうなっているか、楽しみにしながらやっていきましょう。

ではまた。

PWA Night vol.57 ~認証・認可〜 にてパスキーの話をしました

ritou です。

これで話しました。

pwanight.connpass.com

発表資料と発表内容を公開します。

発表資料

speakerdeck.com

発表内容

台本チラ見しながら話したので実際にはこのとおりになってなかった部分もあります。

今日は、パスキーについて話します。

細かい自己紹介は省略します。 色々宣伝したいものがありますがブログに書きます。

今日の内容ですが、初めにパスキーの概要についてざっと触れます。 続いてWebアプリケーションにパスキーを導入するとなった場合にどこから手をつけるべきかというところに触れた後、一番の悩みどころになりそうなログインのUI/UXについて紹介します。

概要からいきましょう。

パスキーの紹介記事もたくさん出ているので要点だけまとめます。

パスキーとは「パスワードが不要な認証方式」であり、それを支える仕様はFIDOアライアンスとW3Cにより策定されています。 最近どこかで見かけた資料にRFCとありましたが、いわゆるWebAuthnはW3Cです。

特徴として、公開鍵暗号による安全性があります。これはネットワークにパスワードのような共有の秘密情報を流さないこと、サービス側は公開鍵のみを保持して漏洩時のリスクを抑えられることがあります。

クレデンシャルの所有者の確認には普段から利用している生体認証などのローカル認証を利用し、パスワードマネージャーによるクレデンシャルの同期機能により、機種変更時や紛失時のリカバリーコストを抑えられるという特徴があります。

サービスからの認証要求に対してブラウザが適切に介入することでフィッシングを検知可能です。 「クレデンシャルを保持している」という所有要素とローカル認証の2要素認証を単体で実現可能なので、パスワード認証の代わりに使えますねというところです。

パスキーの現状として、去年からプラットフォーム、ブラウザの対応が進められました。 具体的にはWebAuthn APIへの対応、パスワードマネージャーへのパスキー保存の部分です。

ある程度動作する環境が整ってきたので、パスキー認証を採用するサービスが増えてきたところが"今"です。 対応サービスが増えると、ユーザーにも馴染みが出てきて、パスキーが使われる状態になるでしょうという流れなのですが、まだまだパスキー対応のプラクティスが十分ではないため、サービスの開発者がまずは先行しているサービスのパスキー認証を利用し、特徴を理解する必要があるでしょう、というのが現状かと思います。

そこでこの本ですね。「まずは使ってみよう。」と。 ここまで話したパスキーの概要についての解説もしているので、是非読んでみてください。

さっきの本を読むと、パスキー対応の意欲が湧いてきます。 ここからはWebアプリというか自サービスに導入するための話をしましょう。

パスワードレスへの道を意識してみましょう。

パスワード認証だけを実装していたサービスは、何らかの攻撃を受けたり、危機意識から2要素認証、2段階認証などを実装しました。 そして、今起きているのは、これまでの認証方式に加えてパスキー認証に対応するというものです。 これができたあと、新規登録時のパスキー登録やパスワード認証の無効化ができると、ようやくパスワードレスが完成します。

しかし、世の中の反応は残酷です。 某Amazonのように、やっとパスキー対応したぞ、となっても「パスワードを無効化できないなら意味ない」みたいな反応がされることもあります。 これはユーザーの期待が現状を超えてしまっている状態だと言えるでしょう。そういえば9月あたりの不正ログインの件はどうなったんでしょうか?

話を戻して、いわゆるパスキー認証への対応としての最低限の実装を紹介します。 それは「パスキーの管理機能」と「パスキー認証を用いたログイン」です。

パスキーの管理機能については、先行して実装したサービスを参考に実装すればある程度迷わずにできるでしょう。

悩みどころとしては、やはりログインのUI/UXのところでしょう。 既存の認証方式に対してどのようにパスキー認証を絡めていくかを考える必要があり、先行して実装したサービスを見ても実装パターンがいくつかあります。

ここからは、ログインUI/UXの実装パターンを紹介します。

まずは Identifier-Firstと呼ばれる実装パターンです。

GoogleAmazonのように、最初にユーザー識別子を入力するパターンです。 これら2つでも細かい違いがあります。

Googleの場合、パスキーの登録状況や環境から、パスキー認証を要求するかどうかを判断します。

Amazonは同様の判断の結果、パスキーでログインするボタンを表示します。あくまでユーザーが選択するもの、という意図なのでしょう。

このIdentifier Firstパターンは、2FAとしてセキュリティキーが利用されていた頃、つまりFIDO認証が始まった当初からあったものと言えます。 「パスワード認証の後にFIDO認証が要求されるフロー」から、パスワード認証が取り除かれてローカル認証が必須になった、と捉えられます。

サービスがパスキー認証を要求するかどうかを判断するわけですが、当然ながら登録されているパスキーがあってもこの環境でそれが利用可能かわかりません。 このため、過去の利用実績を何らかの方法で覚えておいたり、パスキーの登録時の情報と現在の環境を照らし合わせる、などをして判断しているところもあると聞きます。

そして、Amazonのようにユーザーに選択させるところはその分ステップが多くなりますね。

続いて、username lessパターンというものです。

GitHubでは、「Sign in with passkey」というボタンがあり、そこからパスキー認証が始まります。

これは、ユーザー名やメールアドレスといったユーザー情報と一緒にクレデンシャルが保存できるようになった、ResidentKeyやClient Discoverable Credentialといったものが出てきた頃UI/UXです。 セキュリティキーしか使えなかったところから、PCやスマホTPMにクレデンシャルを保存できるようになったあたりですね。

ボタンを押すとこの端末で利用可能なパスキーで認証する、という流れですが、こちらもボタンを押すまで利用可能なパスキーがあるかはわかりません。また、パスキーが登録されていないユーザーも間違って押してしまうかもしれません。この辺りが課題としてあります。

最後に紹介するのが、Passkey AutofillやConditional UIと呼ばれるものを利用するパターンです。

ここで、少し視点を変えてパスキーを考えてみましょう。

パスキー認証は「パスワードマネージャーを利用したパスワード認証」をより進化させた認証方式なのです。 パスワードマネージャーの利用を強制させた上で、「公開鍵暗号方式」と生体認証などの「ローカル認証」を組み合わせたFIDO認証を実現できます。

パスワードマネージャーを利用したパスワード認証では、次の部分がパスワードマネージャーやプラットフォームに依存します。 同一サービスとして扱うかどうかのドメイン判定、パスワード保存時のユーザー名やメールアドレスの扱い、候補として出てきたパスワードを選択した後のユーザーアクションなどです。 また、フィッシング耐性という面では手動のコピペが可能であることが抜け穴となりますし、そもそもサービスはユーザーにパスワードマネージャーの利用を強制できません。

Passkey Autofillではパスワードの時と同様のUXを実現できます。 その上で、対象のドメインやオリジンの値、ユーザー情報をサービスが指定できますし、パスワードのコピペ的なものはありません。

選択後にローカル認証を必要とするかについても、サービスが指定できます。

このPasskey Autofillに対応するサービスも増えてきています。

私が関わっているMIXI Mというサービスは、パスワード認証を利用せずSMS/Email OTPによる認証を採用してきましたが、Passkey Autofillに対応しています。

ユーザー識別子を先に入力するIdentifier FirstパターンのようなUI/UXにもPasskey Autofillを適用可能です。

Passkey Autofillを活用しているサービスとして、マネーフォワード IDがあります。 Identifier Firstパターンを採用しているサービスでは2回Autofillの選択を行う必要があるところも多いですが、 マネーフォワード IDではメールアドレス入力フォームがあり、そこでAutofillの選択を行うとパスワードの場合でもスルッとログインできます。

「パスキーでログイン」というボタンを押させるという新しい体験をさせずに、これまでと同様の体験のままパスキーを利用可能にしているところは現状最も参考になるUI/UXだと言えるでしょう。

まとめです

Auth屋さんの本を買ってパスキー認証の特徴を正しく押さえましょう。

Webアプリケーションへの導入において、最低限の機能は「パスキー管理」と「ログイン」であることを意識しましょう。

ログインのUI/UXは3種類ぐらいに分類できて「Passkey Autofill」がオススメです。

質問など、いつでもお待ちしています。 ありがとうございました。

質問があったら?

Xでこの記事へのリンクをつけつつ聞いてもらえたらと思います。

ではまた。

共有端末におけるパスキー利用可否の解像度を上げる

ritouです。

Xを日々パトロールをしていると、共有/共用端末(これ正式な用語としてはどっちなん?以下、共有と呼びます。)でのパスキー利用について思いを馳せる人が目につくようになりました。

だいたいの人は

共有端末ではパスキーは使えない!完

という認識でしょうけれども、実際どうなんでしょうか?

今回はもうちょっと解像度を上げるための細かい話をしましょう。

共有する範囲

まずは 共有端末と言っても、実は細かく色々あるんじゃないの? というところです。

サービスを利用するにあたって、ユーザーが専有できる範囲はどこなのか、複数ユーザーと共有する範囲はどこなのかというところがいくつかあるでしょう。

  • (A) 端末ごとにユーザーが異なる: 個人PCやモバイル端末を利用
  • (B) 端末のプロファイル(ログインユーザー)が異なる: 会社のPCに社員がログインして利用
  • (C) 端末のプロファイルは一緒、ブラウザのプロファイルが異なる: ユーザーが複数のGoogle Workspaceアカウントを持っており、アカウント毎にChromeのプロファイルをわけて利用
  • (D) 端末、ブラウザプロファイルまで一緒: 家族で使うなんとかかんとか

(A), (B)あたりは個人端末扱いと言えるでしょう。(D)もわりと直感的です。 (C)は他人とというよりも個人で複数アカウントという感じかもしれませんが、Google視点では別人ですよね。なので、このあたりから共有端末と呼んでも良いのではと思います。

この記事ではここまでの整理にして、その先の利用者の多様性(家族、ネットカフェのユーザー、会社の訪問者、市役所の訪問者)みたいなところは考慮しません。

パスキーが使えるかどうか の判断においては、この共有範囲に対してパスキーの管理方法が一致するかによって決まります。

Authenticatorの種類

これはだいたいイメージできているものだと思います。

  • (1) プラットフォームアカウントに同期されたパスワードマネージャー : iCloud Keychain, Google Password Manager
  • (2) 端末のプロファイルごとに管理: ちょっと前までのTPMに保存されるやつ
  • (3) 外部のパスワードマネージャー: 1Password
  • (4) ブラウザプロファイル単位で管理: (2)よりもうちょい細かく管理されたやつ。MacOSChrome
  • (5) セキュリティキー: Yubikey
  • (6) 手元のモバイル端末で管理: Hybrid Transportでモバイル端末を利用

この(A)-(D)と(1)-(6)について、組み合わせで考えていけば良いのです。

共有範囲に対して利用可能なAuthenticatorの種類

猫に表にしましょう。

共有範囲 利用可能なAuthenticatorの種類
(A) (1), (2), (3), (4), (5)
(B) (1), (2), (3), (4), (5)
(C) (4), (5), (6)
(D) (5), (6)

こんな感じで、共有する範囲が広がるほどに利用可能なAuthenticatorの選択肢が限られてくるわけです。

ということで、(D)のように同一ブラウザプロファイルでユーザー認証が必要なケースの場合、

  • セキュリティキーを配布して利用
  • Hybridで手元のモバイル端末を利用

あたりのUXやパスキー管理自体で運用可能かどうかを判断する必要があります。

エンタープライズ領域のようにセキュリティキーの管理が可能なケースだったら良いでしょうし、Hybridの方はスマホアプリ+モバイルアプリでパスキーを生成しつつ店頭の端末でパスキーを利用みたいなこともあるかもしれません。

まとめ

細かく考えると 共有端末におけるパスキー利用はAuthenticatorの種類が制限されるものの不可能ではないかもしれない というお話でした。

きっかけ

今回の記事のきっかけはこちらのニュースです。

www.asahi.com

県病院局によると、看護師は2018年1月~今年1月、勤務時間中に同僚医師の電子カルテのパスワードを使い、アトピー治療用の軟膏(なんこう)や飲み薬の処方箋を計22回不正発行した。

県は電子カルテに2段階認証を導入するなど、再発防止を進めるとしている。

操作したのはブラウザではなく専用ソフトとかなんでしょうけども、こういうケースは(D)の環境と言えるでしょう。

コンビニのレジのようにバーコードで識別するぐらいの要件ならまだしも、

有印公文書偽造・同行使の疑いで県警に刑事告発

みたいなことになるぐらいの要件であれば、セキュリティキーを用いたFIDO認証を実装してみたらどうかなと思いました。

ではまた。

え? OAuth 2.0 の Access Token も JWT じゃなかったの?と思っている皆さん

こんばんは、ritou です。

パスキーの記事ばっかり書いてないでたまにはOAuthのことも取り上げましょう。

OAuthのAccess Tokenについて少し復習してみましょう。

OAuthのAccess Token ってJWTじゃないの?

これについては、我らが Auth屋さん がお話しする会みたいなので自分の方でもいくつか勝手に質問に答えた中にありました。

www.rfc-editor.org

1.4. Access Token

Access tokens are credentials used to access protected resources. An access token is a string representing an authorization issued to the client. The string is usually opaque to the client. Tokens represent specific scopes and durations of access, granted by the resource owner, and enforced by the resource server and authorization server.

と言うように、ここでは opaque = 不透明?ぐらいしか定義されていません。

www.rfc-editor.org

This specification defines a profile for issuing OAuth 2.0 access tokens in JSON Web Token (JWT) format. Authorization servers and resource servers from different vendors can leverage this profile to issue and consume access tokens in an interoperable manner.

JWTのフォーマットを決めたらRSとASが異なるサービスの場合でも互換性取りやすいと言うところです。

Access Tokenの設計については、素晴らしい解説記事があります。

qiita.com

JWTかどうかわからないならClientはデコードできないのでは?

ClientはOAuthのAccess Tokenをデコードする必要はありません。

この思い込みはどこから来るのでしょうか?

いわゆる OAuth認証 においてリスクを回避するためにアクセストークンの発行対象が正しいかどうかを検証すべきみたいな話がありました。そのために、Clientはアクセストークンが自分に対して発行されたものであることを確認できるべき、JWTなら署名検証してPayloadを見たら確認できるじゃんと言うところから来ているのではないかと思っています。

OAuthにおける各種トークンのAudienceとは誰でしょうか?

  • Authorization Code: Token Endpoint
  • Refresh Token: Token Endpoint
  • Access Token: Protected Resources

となります。素晴らしい解説動画があります。

www.youtube.com

Clientはこのトークンを使ってRSにアクセスしろ、と言うだけの話なので中身を知る必要はありません。 上記のように、ClientがATの中身を気にする必要があるケースは、何かしら設計が間違っている可能性があります

ちなみに、OIDCのIDTokenはClient(RP)ですよ。

最後に

JWT な Access Token と言えばこの人ですね。

RFC 9068 の Author

R.I.P.

認証レベルの概念を取り入れたパスキー導入とユーザーへの影響

おはようございます 自称パスキー👮‍♂です。

様々なサービスでパスキー対応が進む中で、今回は特定機能の保護を目的とした導入とユーザーへの影響について取り上げます。

きっかけ

ここ最近、🚔パスキーに関するパトロール🚔をしている中で、メルカリのパスキー導入についてこんなTweetを見つけました。

まずは1つ目です。

新しいパスキーを追加しようと思ったがパスキーがない。

事務局でパスキーをクリアしてもらった

別件で、2台めのAndroid端末で詰みかけた人がいました。

2台目の端末でパスキーが設定できない

1台目の端末からHybridで2台目につないでパスキーを作らないとダメ

マニュアル見てもわからん

この2種類のTweetを見るとメルカリのパスキー対応が単純にgdgdに見えなくもないですが、本当にそうでしょうか? こういう意図でこうなってるんだろう、でこれを改善するために頑張るならここだよねみたいなお話をします。

認証強度、認証レベルとは

ユーザー認証の方式について、パスワード認証、ワンタイムパスワード、認証用のモバイルアプリ、FIDOなど様々なものがあります。 よく人類にはパスワード認証は早すぎるとか言ってそれぞれの特徴を並べて...とやってますが、今回はそれはやりません。 今回はこれらの認証方式にそれぞれ定義される認証強度、認証レベルといったものに注目します。

有名なものでいうとやはりNIST SP 800-63Bの定義でしょう。 FIDOアライアンスから以前出されたホワイトペーパーでもパスワード認証は1、(パスキー登場以前のデバイス単位にクレデンシャルが保存される)FIDOは3相当の扱いだと触れられています。

NIST(米国立標準技術研究所、National Institute of Standards and Technology)はこの状況をデジタル・アイデンティティガイドライン、NIST Special Publication 800-63B に反映しています。このガイドラインでは、3 種類のセキュリティレベル(「AAL」、「認証器の保証レベル」)について概説しています。AAL1(最低レベル)はパスワード、AAL2 は(フィッシング耐性を必要としない)多要素認証、AAL3 はハードウェア ベースのフィッシング耐性のある認証メカニズムにおよそ対応しています。これらのセキュリティ・レベルに照らし合わせると、大多数のコンシューマーはオンライン認証の際に AAL1 を使用しています。多くのエンドユーザーは、例えばオンラインバンキングの利用時などに AAL2 を求められるようになってきていますが、AAL3 が求められることはほ とんどありません。

現在、FIDO 認証は、フィッシング耐性を備えたハードウェアベースの認証器によるもので、従来の AAL3 スタイルのスマートカード認証に代わる素晴らしい選択肢となっています。

参考URL:

openid-foundation-japan.github.io

speakerdeck.com

例えばMicrosoftは、NISTの定義を満たす認証器の組み合わせはこれですよというドキュメントを出していたりします。

learn.microsoft.com

このNISTのAALは様々なガイドラインで"参照"されているので、「この機能を利用するサービスはNISTのAALでこれを満たす認証器を利用する必要がある」みたいな制約があったらそれに従う必要があります。一方で、全てのサービスが必ずこの定義を使わなければならないわけではありません。 当然ながら、サービスが独自にAALを定義をして設計に利用することもありますし、NISTのAAL定義に沿った上で細かい優劣からレベルを定義して利用することもできます。 例えば、クレデンシャルが同期されることでNISTのAAL=3を満たせないと判断されるようになっているパスキーですが、フィッシング耐性という点で他の認証方式(SMSや認証アプリなど)とパスワード認証を組み合わせたものよりもレベルが高いもの、として扱うなどです。 自分が関わるサービスではパスワード認証を利用していないので、SMS/Email OTPでの認証レベルを "一番低いもの" 、パスキーとして同期されうるようになったFIDOクレデンシャルの扱いをざっくり "それより高いもの" としてサービス独自のAALを定義しています。 この後説明しますがメルカリもそんな感じなのではと想像しています。

単純にログイン方法を増やす目的でパスキーを採用!という場合は、特にこのような認証レベルを意識する必要はありませんが、決済、金融関連やヘルスケアのようなセンシティブなデータを扱う機能を保護するためにパスキーを採用する場合は認証レベルを意識する必要があります。 最初に取り上げたメルカリの挙動も認証レベルを意識した設計となっていることにより生まれたものと言えるでしょう。

メルカリのパスキー管理と認証強度に対するポリシーを想像してみた

3行 + αで説明すると、こんな感じなのかなというところです。

  • ビットコイン関連取引ではパスキーの認証が必要
  • パスキーの認証を行うためにはパスキーの登録が必要
  • パスキーの登録時にその時点の最大の認証レベルを実現するための認証方式が要求される
    • パスキーが設定されていない場合はSMS OTPによる認証
    • パスキーが設定されている場合は登録済みのパスキーを用いた認証

例えば、悪意のある攻撃者がAiTMなどでパスワード + SMS OTPを取得してログインセッションを奪い取ることを想像してみましょう。 HTTP Cookieなどで実現されるログインセッションを取得できた攻撃者は、自分自身の端末でログイン状態を再現しつつSMS OTPの値を中継してパスキー登録といった攻撃も考えられなくはありません。若干めんどくさいですが技術的には可能でしょう。

メルカリではこの脅威を認識し、リスク軽減のための設計として以下のように

  • まだパスキーを設定していない状態では、SMS OTPで確認したユーザーを本人とみなすしかないので、(環境判定なども可能なものの)そのまま設定させる
  • 2個目のパスキーを登録する場合は1つ目のパスキーを用いた認証の方がAALが高いため、そちらを要求するという仕様となっている

となっていると想像できます。ここまでは特に筋が悪いものでもないですよね?

「せっかくパスキーが登録されているのに、それより認証レベルが低い認証方式でパスキーを登録させるわけにはいかんよね」というメルカリ側のポリシー と、「パスキー=同期されると言えどもプラットフォームが異なったりブラウザ、端末の関係によっては同期されないことがあるんよな」という実情 の噛み合わせにより、どうしても詰んでしまうケースが出てきてしまうというのが最初に紹介したTweetにつながっています。

設計のポイントは、ユーザーがとりうる認証レベルの最大値

メルカリのような特定機能を保護する目的でパスキーに対応しようとする場合、重要なのは "ユーザーが取りうる認証レベルの最大値" を把握できるようにすることです。

メルカリは毎回認証を要求されるわけですが、そうではなくログインは最初の一回だけで必要ならば追加認証や再認証を要求するといった実装も考えられます。サービスのセッション管理や再認証のポリシーなんてのは本当にサービスに依存するわけですが、例えば

  • メルカリのように都度認証を要求する場合、その時に取りうる認証レベルの最大値を実現する認証方式を要求する
  • 都度認証は要求しない場合でも、現在のセッションの認証レベルユーザーが取りうる認証レベルの最大値を比較して最大値に足りない場合は再認証を要求する
  • さらに最終ログイン日時や環境判定などを組み合わせる

といった設計が必要となり、最も基本となるのが認証レベルの最大値なのです。

同期が可能なパスキーでもリカバリーは重要

パスキーをApple/Google/MSが表明した際、たくさんの人が「プラットフォームを超えて鍵が同期される?なんか良さそう!」って感じになりました。実際はプラットフォーム単位だったり、AppleはクロスデバイスなのにGoogleAndroid端末同士の同期だったり、MSは何してるんだろと思ったら最近やっと対応始まったみたいな感じになってたり「これじゃない感」が出ました。

残念ながら、どうしても「パスキーを設定しているのに使えない状態」というのが存在します。そして、厄介なのがパスキーの認証強度は他の認証方式よりも高いため、代替の方法を用意することが現状では困難だということです。

今回注目したメルカリでは詰んだ時に、どうするか、というところで、

  • 最初にパスキーを登録した端末ではパスキー認証ができるわけなので、その端末からQRコードでモバイル端末などのパスキーを登録して使えるようにする
  • 登録済みのパスキーをCS側でリセットすることで、パスワード + SMS OTPを最大の認証強度として扱うように戻し、新しい端末からも再度パスキーを登録可能にする

ユーザー自身の対応ができるとクレーム含め問い合わせを回避できます。しかし、例えばTOTPとバックアップコードのようにパスキーと対になる方法が確立されているとは言えません。そのような状況において機種変更で古い端末を回収/廃棄されてしまった場合はユーザー自身による対応は困難ですし、Hybrid Transportも全ての端末間で相互に利用できるわけではありません。

ユーザー自身で対応することができないケースを救うため、CS対応において本人を確認した上で後者のようなことができます。 ここからはパスキーと関係ない部分ですが、決済機能を扱っているなど、いわゆる本人確認の仕組みで本人確認書類を提出して属性情報を検証しているサービスの場合はそれを使って本人が問い合わせをしてきたことを確認したりします。そこがうまくできれば、その後のリセットや一時的なパスキー登録を許可する仕組みを用意することもできるでしょう。 最近というかずーっと色々言われているマイナンバーカードを用いた認証の仕組みや、今後作られると言われているスーパー認証アプリ?みたいな仕組みでこの辺りの負担を減らせるようになることを期待しています。

まとめ

  • メルカリは特定機能を保護するためにパスキーを利用しており、パスキーの登録時にはユーザー毎に最大強度の認証方式を要求するため、新しい端末などで登録済みのパスキーが使えない場合に影響が出る
    • 最初にパスキーを登録するとそれが最大強度の認証方式となり、その後はパスキーが同期されている端末もしくは手元でパスキーの認証が可能な端末からHybrid Transportで2台目を登録する必要がある
    • CS経由でパスキーの設定をクリアすることで最大強度の認証方式がパスキーではなくなり、そこからまたパスキーの登録が可能となる
  • セッション管理のポリシーはサービス毎に異なるものだが、認証強度(AAL)の値と認証方式の組み合わせを使って設計するのが良さそう
  • プラットフォームアカウントによる同期は完全ではないので、なるべくユーザー自身で実現可能なリカバリー方法を用意しておきたいが悩ましい

今回取り上げたメルカリと同様に、特定機能を保護する目的でパスキーに対応するサービスが今後は必ず出てきます。これは断言できます。 メルカリにはもう少し人柱的な立ち位置でがんばってもらいつつ、 少しずつこの辺りのユーザー教育と回避策の検討などを頑張り、パスキーの安全性を利用できる世界にしていきましょう。

ではまた!

パスワードとパスキーの違いをクレデンシャル管理の観点から整理する

こんにちは、ritouです。

今回はクレデンシャル管理の観点からパスワードとパスキーによる認証を整理してみます。これまで何回かTwitterに書いてきたお話です。

背景

最近はだいぶパスキーの説明記事なども出てきていますが、

  • パスワードとパスキーによる認証を比較、説明しようとしても色々違いすぎて何だかピンとこないと言われることがある(普通に自分の説明不足もある)
  • パスワードマネージャーについての認識も人それぞれ結構違って、「パスワードレスな世界ではパスワードマネージャーがいらなくなるのである(キリッ」 みたいな書き方もされたりする
  • 「とにかく安全なパスキー🩲」ぐらいの人の解像度をあげたい

と言ったあたりからこれを書きました。

比較対象

今回は以下の3つのクレデンシャル管理を用いた認証方式の差分をみていきます。

  1. 記憶により管理されている パスワード
  2. システムにより管理されている パスワード
  3. システムにより管理されている パスキー(FIDOクレデンシャル)

それぞれの特徴、そして1と2の違い、2と3の違いを整理します。

1. 記憶により管理されているパスワードを用いた認証

いつも “人類にパスワード認証は早すぎる” みたいに言ってるやつです。

特徴としては

  • Pros
  • Cons
    • 推測困難なパスワード生成が困難 -> 第3者によるログイン
    • あまり多くのパスワードを管理できない -> 使い回し
    • いわゆる二段階認証を導入してもフィッシングにやられてしまうことが多い

と言ったところでしょう。

2. システムにより管理されているパスワードを用いた認証

OSやブラウザから提供されるパスワードマネージャーと言われているようなものを使う場合はこれにあたります。 特徴は1と2でガラッと変わります。

  • Pros
    • 推測困難なパスワードを生成できる
    • 多くのサービスのパスワードを管理できる
    • 自動入力するかどうかはシステムがURLなどを用いて判断し、異なるドメインなどにあるフィッシングサイトにはメールアドレスなどの識別子とパスワードが自動入力されない
  • Cons
    • 共通のパスワードマネージャー相当のものがインストール/OS機能として提供されていて、パスワードが同期されている環境でのみ利用できる
    • ユーザーが手動でパスワードなどをコピペすることでフィッシングの被害に遭うこともある
    • あくまでシステムで管理されるのはパスワード入力の部分までなので、認証フローの中のリクエストにはパスワードそのものが含まれる

と言うように、完全にとは言えないものの概ね反対の特徴を持っています。

Consにあるように、ユーザー自身が余計なことをしてフィッシングにかからなければ 記憶により管理されているパスワードを使う認証の ユーザー側の課題は大体解消できます

パスワード認証を利用する限り、サービス側から復号可能な状態で漏洩して...みたいな課題はあるものの、システムにより管理されることで安全性が高まることは明白です。

パスワード vs パスキー、パスワードからパスキーみたいなところに触れるところに、ここをすっ飛ばして「全く別物」として説明するよりは1段階入れることで特性の違いが理解しやすくなるのではないかと考えています。

3. システムにより管理されているパスキー(FIDOクレデンシャル)

システム管理されたパスワードにより課題がクリアされるとなると、パスキーのメリットはどう考えたら良いの?となりそうです。

残念ながら、人類は公開鍵暗号で利用する鍵ペアを手動で生成したりバイナリ/JWK/PEM形式とかで記憶したり、脳内でデジタル署名を生成したりはできません。なのでFIDOではそのクレデンシャルの管理をAuthenticator(認証器)が行います。

FIDOクレデンシャルはシステムにより管理されることが前提であり、ユーザーに対してそれを強制する仕組みであるとも言えます。

特徴としては

  • Pros
    • 暗号的に安全な鍵ペアを生成できる
    • 多くのサービスの秘密鍵などの情報を管理できる
    • WebAuthnは認証フローの中でブラウザが仲介することで現在アクセスしているoriginとサービスが指定してくるrp_idの比較を行い、一致しない場合はFIDOの認証が走らないのでフィッシングが困難
    • プラットフォームや外部のパスワードマネージャーの同期がされている他の環境からも利用できる
    • 認証の際のリクエスト/レスポンスには秘密鍵そのものの値は含まれない
  • Cons
    • プラットフォームや外部のパスワードマネージャーによりFIDOクレデンシャルの同期がされていない環境からは利用できない

と言うところでしょう。

2との差分としては公開鍵暗号に関する部分とフィッシング耐性の話、そして繰り返しになりますが、システムによる管理を強制できるところです。

このように段階的に整理していくと、いわゆるパスキーの仕組みは パスワードマネージャーの仕組みを強化し、ユーザーに強制できるもの と捉えることができるでしょう。

やり取りされるデータとクレデンシャル

パスキーの説明でよく語られる部分ですが、認証時にサービスに送られるデータの観点でいうとパスワード認証はリクエストにクレデンシャルが流れ、FIDOは通信路にクレデンシャルが流れないみたいな違いはあります。 これは認証方式による違いの話で、今回の整理の本質であるクレデンシャルの管理とは関係ないですね。

システムによる管理における、クレデンシャルの共有範囲による違い

現在の “パスキー” の流れが登場する前、FIDOクレデンシャルはYubikeyのようなセキュリティキーやPC/スマホ自体のTPMに保存されるものとして扱われてきました。 それがプラットフォーマーのクレデンシャル管理の仕組みを利用するようになり、最近は外部のパスワードマネージャーによる管理も始まりました。

そもそも、このような流れになった背景としてFIDOクレデンシャルを保存している端末が使えない状態になった際にリカバリーが困難と言う課題がありました。 FIDOクレデンシャルが共有されたり同期されたりして複数端末から利用可能になると利便性が向上するものの、あるFIDOクレデンシャルを第3者が入手するためのハードルが下がることになります。クレデンシャル管理の方法に応じて、頼らざるをえないセキュリティ機構の対象が変わります。

  • 端末ごとのTPMに保存 : 端末ごとのセキュリティ
  • プラットフォームアカウントに紐づけて管理 : プラットフォームアカウントのセキュリティ
  • 外部のパスワードマネージャーで管理 : 外部のパスワードマネージャーのセキュリティ

パスキー認証を利用するサービスがどの程度の安全性を必要としているかを判断、要求しつつ、その中からユーザーが選択できるのが理想ですが、実際はこの辺りは難しいでしょう。この辺り困るのは "端末ごとのTPMに保存"相当のセキュリティ要件があるサービスですが、まぁその辺りは一旦置いておきましょう。

今回の整理において言いたいのは これはパスキー独自の検討事項ではなく、システムにより管理されているパスワードも同様である ということです。

まとめ

  • 記憶で管理されるパスワードとシステムで管理されるパスワード、それぞれを利用する認証は特性がガラリと変わり、システムで管理されるパスワードによって一般的なパスワード認証のデメリットはだいたい解消できる
  • システムで管理されるパスワードとFIDOクレデンシャルの違いは、FIDOの仕様に関連する公開鍵暗号フィッシング耐性の詳細の部分と、システムによる管理を強制できるかどうかで違いがある
  • パスキーの認証はパスワードマネージャーを強化し、ユーザーに強制できる仕組みである
  • システム管理において、共有/同期の範囲と依存するセキュリティ機構が変わる話はFIDOクレデンシャルだけの話ではなく、パスワード認証でも同じ

今回はUI/UXの話を入れませんでした。入れるとそれだけでもう一記事かけるぐらいになりそうなので別にします。

色々な観点から物事の変化を捉えることも大事ですね。 ではまた。

β公開された1Passwordのパスキー対応について調べてみた

こんにちは、ritouです。

β公開から少し時間が経ってしまいましたが、1Passwordのパスキー対応について確認して整理しました。

www.publickey1.jp

これまでAppleiCloud KeychainやAndroidGoogleパスワードマネージャーなどが プロバイダとしてのパスキーのサポートをしてきた中で、1Passwordが同様の対応をすることでクロスプラットフォームなパスキー利用環境が整うのか?と注目が集まっています。

個人的に1Passwordを活用しているので、使い勝手を見てみました。

環境は Chrome バージョン: 114.0.5735.133 @ macOS です。 1Passwordのβ版の拡張機能を有効にすることで動作確認ができます。 Relying Partyにはwebauthn.ioを利用します。

webauthn.io

パスキーの生成/登録

Webサービスでは、アカウントの新規作成の際や設定変更などでパスキーの生成、登録を行います。特に新規作成時はなるべくシームレスに完了できることが重要な処理ですね。

何も考えずに生成/登録を行おうとすると、このようなプロンプトが表示されます。

1Passwordのアンロックを忘れていたので生成ができませんでした。アンロックして1Passwordが利用可能な状態にして再度試してみます。

こんな感じでパスキーを生成して保存しますよとなります。

これで、1Passwordにwebauthn.ioで利用するパスキーを生成できました。生成したパスキーはパスワードと同様に確認できます。

実にスムーズにパスキーの生成/登録ができました。むしろ、スムーズすぎる気がします。

これまで1Password以外のパスキー生成のフローにあったTouchIDやFaceIDとか指紋認証、PINなどのローカル認証が求められませんでした。技術的には、UserVerificationを要求しているのにすっと生成できてしまったんだが? というところです。

後から直接1PasswordのTwitterアカウントに聞いてみたら教えてくれたんですが、1Passwordが利用可能な状態=1Password自体がパスワードなどでアンロックされた状態であるので、UserVerificationが済んでいる扱いなのだ ということらしいです。 その観点で言えば、なるほど...となりますが、これまでのFIDO仕草をこれだけあっさり変えてもいいものなのか...と思ってしまいます。

もう一つ、これは仕様かバグか表現に迷う部分ですが、ある1Passwordアカウントに対して保存できるパスキーは1つだけとなっている気がします。別にそれ困らないのでは?という感じですが、例えばサービス側のuser1, user2に対してそれぞれパスキーを生成/登録しようと思っても1Password上では単一のパスキー管理が上書きされるような挙動になっていました。 その結果、user_1に対して後から生成/登録されたuser_2のためのパスキーが保存されたりします。 これはさすがによろしくない挙動だと思うのでサービス側から受け取った識別子に紐づけられた複数のパスキーを登録できるとか(追記:もしくはVaultを分けるように促せ)とった改善をしてもらいたいところです。

パスキーを用いた認証

それではさっきのパスキーを用いてログインするところを確認しましょう。

今度はこんな感じのプロンプトが出てきて、ログインできます。 生成のところと同様に、ローカル認証は求められません。理由も一緒です。

Autofill

マネーフォワード IDが本格的に導入してパスキーのログインUXのキモだとも思っているAutofillの動作も確認してみます。

生成の部分は上記と同様にできました。 さて、Autofillを用いたログインはどうでしょうか。

1PasswordのプロンプトとChromeのプロンプトで渋滞です。 ここで1Passwordのプロンプトを選んでも識別子が入力されるだけでした。Chromeのプロンプトからは1Passwordのプロンプトが立ち上がりません。よって、少なくともこの環境ではAutofill対応ができていないということでしょう。 この辺り興味がある方がいたら他の環境でも試していただければと思います。

他のパスキープロバイダとの併用

パスワードの時点でもうだいぶカオスになってる部分ですが、Chrome管理のパスキーと1Password管理のパスキー両方がある場合に、いい具合に使えるのか?というのも気になります。

生成のところでは、キャンセルするとChromeのプロンプトが出て来るので、手元の端末やhybrid transportと呼ばれる仕組みで繋いだモバイル端末にパスキーを生成できます。これはまぁまぁ良さそう。

ログインに関しては、識別子を先に入れたり入れなかったりと色々なパターンがあるのですが、

  • サービス側から1Password以外に管理されているパスキーが指定された場合 : 1Passwordは何も干渉してこないので使える
  • サービス側から1Passwordとそれ以外に管理されているパスキー両方が指定された場合 : 1Passwordのプロンプトが出てきて、しかも❌ボタンのキャンセルが効かないので実質1Passwordのパスキーしか使えない
  • サービス側からパスキーが指定されない状況において、1Password以外に管理されているパスキーしかない場合 : 1Passwordは何も干渉してこないので使える
  • サービス側からパスキーが指定されない状況において、1Passwordとそれ以外に管理されているパスキーが存在する場合、 : 先に1Passwordのプロンプトが出てきて、しかも❌ボタンのキャンセルが効かないので実質1Passwordのパスキーしか使えない

という状況でした。生成/登録だけではなく認証の部分もChromeにフォールバックさせて欲しいところです。

まとめ

1Passwordのパスキー対応について調べました。

  • パスキー生成/登録、ログインをするためには1Passwordのアンロックが必要で、それがされている=UserVerificationが行われた状態なのでローカル認証は呼ばれない
  • パスキー生成はスムーズに完了できるが、サービス側の複数ユーザーの時に1Passwordでは最初のユーザーに対する鍵情報の更新になりそう
  • ログインについて、こちらもローカル認証が呼ばれないので単一ユーザーのログインについてはスムーズにできるが、キャンセルできないのはおかしい
  • Autofillには非対応の模様
  • 既に別の仕組みでパスキーを管理していて1Passwordでもパスキーを管理する場合、その後は1Passwordのプロンプトが先に出てくるので注意が必要。いちいち拡張無効化めんどい。

キャンセルできないとかAutofillに対応していないとかは今後も機能改善などが行われるかと思いますが、ローカル認証が都度呼ばれない点については、利用するサービス側が「必ず毎回ローカル認証呼ばれる前提」で作られていた場合に想定と違う挙動になり得るので気になっています。

モバイルアプリでの対応含め、この辺りは今後も追っていく予定です。

そういえばBitwardenも同様の対応、さらにBitwarden自体へのログインでもPasskeyが利用できるようになったそうじゃないですか。 クロスプラットフォームが実現できるのか、様子を見ていきましょう。

ではまた。

おまけ:UserVerificationについて聞いてみたメモ

プラットフォームアカウントに紐づけられたクレデンシャルを利用するユーザー認証について

おはようございます、ritouです。

何の話?

最近のユーザー認証を取り巻く状況について、次の2つの事例の共通点を考えましょう

  • Passkey(FIDOアライアンスが言ってるMulti-Device FIDO Credentialsの方)はFIDOクレデンシャルがApple/Google/MSといったプラットフォーム(など)のアカウントに紐づけられる仕組み
  • Google Authenticator のクレデンシャル管理がデバイス単位からGoogleアカウントに紐づくデバイス間で同期されるように変わる

これらは "クレデンシャル" と呼ばれる、秘密鍵やパスワードなどの "認証のための情報" をデバイス単位ではなくプラットフォームアカウント単位に保存/管理するというお話です。

そのおかげで、新しいデバイスを使い始める際にこれまで利用してきたサービスに対して色々と設定しなおすことなく、AppleGoogleアカウントを設定してゴニョゴニョするだけで今までのデバイスと同様に利用できますよ、というのが謳い文句となっています。

本投稿では

  • 「プラットフォームアカウントに紐づいたクレデンシャルを利用する認証デバイス」をどう捉えるべきか
  • プラットフォームアカウントとのID連携との違い

について考察します。

Google AuthenticatorのE2EEの話はしません

認証方式とクレデンシャル管理

世の中で使われているいくつかのユーザー認証の説明において、いわゆる認証要素と呼ばれるもので分類されることがあります。 私たちは以下の3つの中のどれか、もしくは組み合わせによってユーザー認証の特徴を表現してきました。

  • 記憶 : Something You Know(SYK)
  • 所持 : Something You Have(SYH)
  • 生体 : Something You Are(SYA)

パスワード認証はSYK, SMS OTPや公開鍵暗号を用いた認証方式はSYH, 指紋や顔を用いたいわゆる生体認証はSYAに分類されます。 FIDOでは、公開鍵暗号方式(SYH)とローカル認証(SYA or SYK)が組み合わせられることで高い認証強度を実現できていると説明されています。

ここまでのところでは、それほどプラットフォームアカウントの概念は出てきません。 そこで一段深掘りして、このようなユーザー認証を実現するためのクレデンシャル管理に着目した時に出てきます。

  • パスワード認証 : 人体の記憶領域、パスワードマネージャー、デスクトップに貼られた付箋、エンディングノート
  • TOTP : 設定したデバイス、もしくはプラットフォームアカウントや専用アプリのアカウントが所有する複数デバイス
  • FIDO/Passkey : 端末やセキュリティキーのTPM、もしくはプラットフォームユーザーのクラウドストレージ

このクレデンシャル管理の多様化によって影響を受けるのが、最初に挙げた3要素の中の所持要素(SYH)です。 クレデンシャルの保存箇所について、当初はユーザー本人の記憶や設定したシングルデバイスのみに保存されている前提が一般的だったと思います。 複数デバイスで(暗号化を駆使しつつ)の同期について語られることが増えたのは、パスワードマネージャーやTOTPでAuthyのような専用アプリが登場したあたりでしょうか。 現状はパスワードもChromeSafariのようにブラウザに関連するプラットフォームアカウントに紐づけて保存する仕組み、1Passwordのようなアプリのアカウントに紐づく管理はもはや普通に行われていますし、PasskeyやGoogle Authenticatorの動向からもその勢いが加速していることがわかります。

プラットフォームアカウントをキーとしてクレデンシャルを奪われるリスク

このようなクレデンシャル管理は端末が壊れた時や新規端末を使い始めたときにとても便利です。しかし、クレデンシャルの漏洩というリスクを考えると頭を抱えてしまうこともあるでしょう。 具体的にいうと、これまで想定されていた "デバイスのコントロールを奪われる" リスクに加えて "プラットフォームアカウントを奪われる" リスクについても考慮する必要が出てきます。

もうちょっと細かい話をすると、"複数デバイスにクレデンシャルが保存されている状態" と "プラットフォームアカウントに紐づけられた複数デバイスでクレデンシャルが同期されている状態" は特性が異なります。 "複数デバイスに..." は単純に管理しなければならないデバイスが複数ある話なのでいずれかのコントロールを奪われることだけがリスクとなるわけですが、"プラットフォームアカウントに..." はプラットフォームアカウント自体のクレデンシャル管理が一番の肝となります。

C向けのサービスであればユーザーの責任でこの辺りちゃんとやってねとなるのかもしれませんが、B向けのサービスとなるとデバイス管理の方法というところから考慮が必要となるでしょう。

これまでも議論を呼んでいたメールOTP

これまでの人生において、いくつかのユーザー認証の方式を比較しながら説明してきました。その中でたまに議論になっていたのが "メールOTP" の扱いです。 ユーザー認証を要求するサービスは対象アカウントのメールアドレス宛にOTPを送信し、受信したOTPを画面のフォームなどに入力することで認証する方式です(リンクを踏ませるものもありますがその辺はおいておきます)。

この認証方式を SYH と捉える場合、所有しているのは "メールを受信できる環境" です。 SMSの場合、"SIMが設定されてSMSを受信可能なデバイス" とすると(通信網に依存はするものの)一意に識別可能な端末として扱えますが、メールに関してはメールアプリに "メールアカウントが設定されている端末" となります。 そのメール設定のためにはメールアカウントのクレデンシャルもしくはメールアカウントを提供するサービスとのOAuthによる設定が必要ですし、その対象はシングルデバイスではなく複数デバイスメーラー、そしてWebアプリだったりもします。このため「メールOTPはSYHの扱いとしてどう扱うべきか」みたいな議論は以前からありました。

今回の "プラットフォームアカウントにクレデンシャルが紐づく" ユーザー認証についても、上記の."メールアカウント" の話に近いものがあります。 ここで "メールアカウントやプラットフォームアカウント、専用アプリのアカウントの認証強度とは?" を詰めていけば全て整理できるのではと考えたくなるのですが、メールアカウントの例で設定方法がパスワードからOAuthの形式に変わったりしてメールアカウントのユーザー認証と分離されるようになったように、 "プラットフォームアカウントがどの認証方式を採用しているのか" というところに依存することで認証強度の解釈が多段というか複雑になり、統一的に語れなくなるでしょう。 よって、今後は "プラットフォームアカウントに紐づく" というクレデンシャル管理のパターンをしっかり定義して、使っていく必要があるででしょう。

プラットフォームアカウントによるID連携との違い

Apple信者という言葉はなんだか信仰のなんたらを意識してしまいそうなので、例えばGoogleプロダクト大好きさんがいたとします。

  1. Google Chrome にパスワード、Google AuthenticatorでTOTPのSecretを保存した状態で2FAでログインする
  2. Android で同期しているパスキーを利用してログインする
  3. Sign In with Google(ID連携)でログインする

これらのユーザー認証はいずれもクレデンシャル管理をGoogleアカウントが支えている状態なので、Googleアカウントがあれば新しいAndroid端末からすぐにこれらのユーザー認証を利用できます。では、1,2 と 3 の違いは何があるでしょうか?

  • 認証方式の違い : 1,2 は認証を行うサービス側からパスワード、TOTP、FIDOという方式を固定してユーザーに要求しますが、3はどの認証方式を利用するかはプラットフォームやユーザー自身により決められます
  • 他プラットフォームアカウントの利用 : 1,2はAppleプロダクト大好きさんであればSafariAppleアカウント、iCloud Keychainのパワーで同じようなことができますが、3はサービスがSign In with Appleに対応する必要があります
  • プラットフォームアカウント情報のやり取り : 3はOIDCの仕組みなどによりプラットフォームアカウントの属性情報をサービスに渡せますが 1,2 は基本的にそれができません。

というところで、1,2はユーザーから見たらプラットフォームアカウントに依存しているがサービス側からは見えない、言うなれば "シャドーID連携" といった感じに見えます。特定のOSやブラウザ、アプリの組み合わせによってはID連携と似たようなUXとなることはあるものの、細かい違いがあること、そして逆にプラットフォームアカウントによるSPOFを避けるためには、パスワードと2FAで利用するクレデンシャルが紐づけられているプラットフォームアカウントを分けるという方法もあるということを意識しましょう。

ユーザー認証に関わるガイドラインについて

ユーザー認証というかIdentity管理について様々な仕様から参照されているガイドラインは "NIST SP 800-63 Digital Identity Guidelines" です。現行のものは63-3というもので、63-4が現在策定中です。

OpenIDファウンデーション・ジャパンによる翻訳に参加された方のTweetで63-3と63-4で今回の話と関連する記述の変更がされているようでその影響ではないか、という意見が見られました。

対象はSP 800-63B Authentication and Lifecycle Managementというドキュメントです。 63-3では複数デバイスでの秘密鍵保持に対して否定的でした。

OTP authenticators — particularly software-based OTP generators — SHOULD discourage and SHALL NOT facilitate the cloning of the secret key onto multiple devices.

63-4ではデバイス変更時にユーザーアカウントに紐付け(て移行し)、古い方消せみたいな雰囲気の記載になっています。

If a subscriber needs to change the device used for a software-based OTP authenticator, they SHOULD bind the authenticator application on the new device to their subscriber account as described in Sec. 6.1.2.1 and invalidate the authenticator application that will no longer be used.

表現の仕方が変わったとはいえ、あまり複数端末でクレデンシャルを同期してどっちもアクティブなまま使えることまでは想定していないように見てとれます。

繰り返しになりますが今までもTOTPを複数デバイスで使える仕組みはあったわけですし、個人的にはこの記載の変更によりGoogleが対応したというよりは時流の流れをNISTが少しだけ汲み取ったという方が適切な気がしています。

今後はシングルデバイスなのかマルチデバイスなのか、それをアプリやプラットフォームアカウントが仲介するのかによって認証強度(AAL)の定義が変わったり、NISTの定義を参照しつつ「この処理を行うサービスではこのような仕組みを利用してはいけない」と言った細かい整理が行われる可能性もあるでしょう。

まとめ

ざっくりまとめると次のようなところでしょうか。

  • クレデンシャルの保存がシングルデバイスからアプリやプラットフォームアカウントへと拡張される事案が増えてきた
  • いわゆる認証の3要素の所持要素の部分に影響する話であるが、単純な複数デバイスにクレデンシャルを保存されている状態とも話が違う
  • NISTの定義も認証アプリをプラットフォームアカウントと紐付けて移行することについての記載がありこの辺りの潮流を意識している気はするが、今後より整理が行われるのではないか

この話をすると「巨大プラットフォーマー、特にモバイル端末を持っているAppleGoogleへの2極化が進んでいるように見える」という感想をいただくことがあります。全てを握られている感は気になるものの、"シャドーID連携" と表現したようにプラットフォームアカウントの管理だけ頑張れば良い仕組みと言い換えることもできるので、今後も動向を見守りたいと思います。

ではまた。