OIDC(OpenID Connect)はSSO(Single Sign On)をどのように実現しているか
ritouです。今日はこの話です。
SSO=一度ログインしたら複数RPに一括でログイン可能みたいなイメージに対して、OIDCでの動きは個々のRPがそれぞれ自分達向けのIDTokenを受け取りそれを信用してログイン状態にするだけ。 https://t.co/R4qNOrcY8h
— 👹秋田の猫🐱 (@ritou) 2025年5月9日
ここで扱うSSO（シングルサインオン）とは、一般的に「一度の認証処理で、複数の独立したシステムやサービスへアクセス可能になる仕組み」を指します。 本稿では、このSSOをID連携の主要な実現手段の一つであるOIDC (OpenID Connect) がどのように実現するのかについて解説します。
ID連携を用いないSSOの実現方法：単一セキュリティドメイン内でのアプローチ
まずID連携について触れる前に、単一のセキュリティドメイン（ID管理が一元的に行われる範囲）内で、複数のサービスがSSOと同様の利便性を提供する方法を振り返ってみましょう。 これは、自社で統一されたID体系を運用している比較的規模の大きな企業グループなどを想像すると分かりやすいです。例えば、exampleという企業グループが以下のようなドメインで複数のサービスを提供しているとします。
service1.example.comservice2.example.comservice3.example.net(M&Aによってグループに加わったサービスや、国ごとにドメインが異なるサービスなど、親ドメインが異なるケース)
この場合、*.example.com で提供されるサービス群（service1.example.com、service2.example.com）では、親ドメインである example.com に紐づけられたセッションクッキーをファーストパーティクッキー（1st Party Cookie）として共有することで、SSOに近い挙動を実現できます。
しかし、ドメインが異なる service3.example.net では、このファーストパーティクッキーの仕組みを直接利用できません。従来は、example.com のセッションクッキーをサードパーティクッキー（3rd Party Cookie）として service3.example.net から利用することでセッションを共有するケースもありましたが、近年はプライバシー保護の観点からブラウザによるサードパーティクッキーの制限が強化されており、このアプローチは難しくなっています。そのため、このようなケースでは後述するID連携が使われるケースもあるようです。
複数セキュリティドメインを繋ぐID連携とSSO
ここから本題であるID連携について説明します。 それぞれ独立したセキュリティドメインを持つ複数のサービス間でSSOを実現しようとする場合、ID連携の仕組みが必要となります。 企業が業務で利用する複数のSaaS（Software as a Service）を連携させるケースを想像すると分かりやすいでしょう。以下のような構成は、現代の企業システムにおいて珍しくありません。
- IdP (Identity Provider):
- IDaaS
- RPs (Relying Parties):
- プロジェクト管理ツール
- 社内ドキュメントツール
- ソースコード管理
これらのRPがIdPとどのように連携してSSOを実現するのか、OIDCの認証フローに沿って説明します。
- ユーザーによるRPへのアクセスと認証要求の開始: ユーザーがRP（例: プロジェクト管理ツール）のログイン画面でメールアドレスを入力したり、企業専用のサブドメイン（例: mycompany.project-tool.com）経由でRPにアクセスします。RPはこれを受けて、認証が必要なユーザーを識別しようとします。
- RPからIdPへの認証リクエスト: RPは、IdPに対してOIDCの認証リクエストを送信します。このリクエストには、RPが必要とする情報（スコープ）や、認証後にIdPがユーザーをリダイレクトさせるべきRPのURL（リダイレクトURI）などが含まれます。
- IdPによるユーザー認証: IdPは、まずユーザーがIdP自身で認証済みであるかを確認します。認証されていない場合、またはRPから要求された認証レベル（認証コンテキスト、例: 多要素認証の要求）を満たしていない場合は、ユーザーに対して認証処理（例: ID/パスワード入力、多要素認証）を要求します。既にIdPで認証済みで、かつ要求される認証レベルを満たしていれば、このステップは省略されることがあります。
- IdPからRPへの認証レスポンス (IDトークンの発行): 認証が成功すると、IdPは認証結果としてIDトークン (ID Token) を生成し、RPに提供します。この際、通常は認証コード（Authorization Code）を介して安全にIDトークンがRPに渡されます（Authorization Code Flowの場合）。IDトークンには、認証されたユーザーの識別子や認証に関する情報が含まれます。必要に応じてアクセストークン (Access Token) も発行され、RPはこれを用いて保護されたリソース（例: ユーザープロファイルAPI）へアクセスできます。
- RPによるユーザーのログイン状態確立: RPは受け取ったIDトークンを検証し（署名の検証、発行元の確認など）、その内容に基づいて自サービス内のユーザーアカウントと紐づけます。これにより、RPはユーザーをログイン状態にし、サービスを提供します。
単一セキュリティドメイン内の中央集権的なセッション管理と比較すると、ID連携はより分散的なアーキテクチャと言えます。SAML (Security Assertion Markup Language) を利用する場合も、基本的な考え方や登場人物の役割はOIDCと類似しています。
RPが複数ある場合も、ユーザーが各RPにアクセスするたびに上記の手順（主に2～5）が繰り返されます。 企業でこのようなID連携によるSSOが導入されている環境での挙動例を見てみましょう。
- 最初のアクセス: ユーザーが初めてプロジェクト管理ツール（RP1）にアクセスします。
- RP1はユーザーが未認証であるため、IdPへリダイレクトします。
- ユーザーはIdPでも未認証の場合、IdPのログイン画面で認証情報を入力し、認証を完了します。
- IdPはRP1へ認証情報を返し、RP1はユーザーをログイン状態にします。
- 次のサービスへのアクセス: その後、ユーザーが社内ドキュメントツール（RP2）にアクセスします。
- RP2もユーザーが未認証（RP2に対しては）であるため、IdPへリダイレクトします。
- この時点でユーザーは既にIdPで認証済みであるため、IdPは追加の認証を要求せず、即座にRP2へ認証情報を返します。
- RP2はユーザーをログイン状態にします。ユーザーは再度ログイン操作を行う必要がありませんでした。
企業利用のシナリオでは、情報システム部門などがIdPに対して認証強度やセッションの有効期限といったポリシー（認証コンテキスト）を設定します。ユーザーが一度このポリシーに従ってIdPで認証されれば、連携する各RPは追加の認証なしに利用可能になる、という挙動が一般的です。 このように、個々のRPとIdP間のID連携を組み合わせることで、実質的なSSOが実現されます。
セッション状態の不整合検知と対応
ID連携は便利な仕組みですが、IdPと各RPのセッションは疎結合であるため、セッション状態に不整合が生じる可能性があります。 例えば、前述のシナリオで、ユーザーがIdPで明示的にログアウトしたり、あるいは管理者によってIdPのセッションが無効化された後、既にログイン済みだったRPにアクセスした場合を考えてみましょう。
- ユーザーAがプロジェクト管理ツール（RP1）にアクセスし、IdP経由でログイン。
- その後、何らかの理由でIdP上でユーザーAがログアウトし、同じブラウザでユーザーBがIdPにログインしたとする。（企業利用では稀かもしれませんが、個人向けサービスではあり得ます）
- ユーザーBが次に社内ドキュメントツール（RP2）にアクセス。RP2はIdPにリダイレクトし、IdPはユーザーBの認証情報に基づいてRP2をログイン状態にする。
この時点で、プロジェクト管理ツール（RP1）はユーザーAでログインした状態のまま、社内ドキュメントツール（RP2）はユーザーBでログインしている、という不整合が発生します。もしプロジェクト管理ツール（RP1）がこの変更を検知できず、ユーザーBがアクセスした際にユーザーAのセッションが継続していたら、情報漏洩や意図しない操作に繋がる可能性があります。 このような不整合状態を検知・軽減するために、OIDCではいくつかの仕組みが提案されています。
IdPのログアウト時にRPへ通知する仕組み
IdPでのログアウトイベントを各RPに通知し、RP側でもセッションを終了させることで不整合を防ぐアプローチです。
- OpenID Connect Back-Channel Logout 1.0: IdPでユーザーがログアウトすると、IdPがそのユーザーセッションに関連付けられた各RPのバックエンドエンドポイントに対して直接ログアウト通知（Logout Tokenを送信）を行います。RP側ではこの通知を受け取り、該当ユーザーのセッションを終了させる処理を実装する必要があります。例えば、デジタル庁の「デジタル社会共通機能における認証に関する実装ガイドライン」でもこの仕組みについて言及されています。
- OpenID Connect Front-Channel Logout 1.0: IdPがユーザーのブラウザを介して、各RPのログアウトエンドポイントを（例: iframe内で）順次呼び出すことでログアウトを伝播させる仕組みです。ブラウザの制約（サードパーティクッキー制限など）の影響を受ける可能性があります。
- OpenID Shared Signals and Events (SSE) Framework (旧称: RISC - Risk and Incident Sharing and Coordination): より汎用的で継続的なイベント通知の仕組みです。Back-Channel Logoutと似た目的（セッション無効化通知など）もカバーしますが、アカウント情報の変更、不正アクセスの検知など、より広範なセキュリティイベントをRPに通知するために設計されており、アカウント関連イベント通知の最新のアプローチの一つです。
これらの仕組みは、ユーザーが正規のログアウト操作を行った場合に有効です。ブラウザのクッキーを直接削除するなど、IdPが関知しない形でセッションが無効化された場合には、通知が届かない可能性がある点に留意が必要です。
RPがIdPに定期的にセッション状態の変更有無を問い合わせる仕組み
RPから能動的にIdPへユーザーのセッション状態に変更がないかを確認するアプローチもあります。
- OpenID Connect Session Management 1.0: IdPはIDトークン発行時に session_state というパラメータを付与します。RPは、この session_state とユーザーのブラウザに埋め込んだIdPドメインの非表示iframe、および postMessage APIを利用して、定期的にIdPにセッション状態の変更を確認します。IdP側でセッション状態に変化（例: ログアウト、別ユーザーでのログイン）があれば、RPに通知され、RPは現在のセッションを終了するなどの対応を取ることができます。
このiframeとpostMessageを利用する方法は、策定時期の技術的背景を反映したものです。現在では、ブラウザの新しいAPIを活用した、より洗練されたセッション状態確認の方法が模索されるべき、と言えるでしょう。FedCMなどが関連しそうでしょうか。
まとめ
今回は、ID連携、特にOIDCを用いたSSOの実現方法と、関連する課題について解説しました。
- セキュリティドメインが異なるサービス間でSSOを実現するには、ID連携の仕組みが不可欠です。
- OIDCでは、各RPがIdPに対して認証を要求し、IdPがそれに応答するという基本的なフローを連携先のRPごとに行うことで、結果としてSSOが実現されます。
- ID連携は本質的に疎結合なシステムであるため、IdPとRP間でセッション情報の不整合が発生する可能性がありますが、これを検知・軽減するためのログアウト通知やセッション管理の仕組みも用意されています。
ではまた。
パスキー関連の案件でユーザー認証方式の変遷について話しました
ritouです。
昨年末から先月ぐらいまで、何度か
- これまでのユーザー認証方式の歴史
- パスキーによって何が実現できるのか
みたいな話をする機会がありました。
まずはSoftware Design 2025年1月号の「第1特集 認証技術の最前線パスワードレス認証「パスキー」のしくみと実装」の前半を担当しました。
そして、ファインディ株式会社様主催のイベントでお話しました。
4月中旬にはAuth屋さんと一緒に株式会社overflow様のイベントでお話しました。
全体通して大体似たような話をしています。
パスワード認証 -> 多要素認証 -> FIDO認証 -> パスキー -> シンプルなパスワードレス認証
- パスワード認証の課題が明らかになり、攻撃が増えた
- 応急処置的に別の認証要素を足し算して多要素認証が一般的に、しかしそれでも突破される手法も登場
- そこからパスワード認証を引き算したシンプルなパスワードレス認証も登場
- パスワード認証の根本的な課題の解決を目指し、FIDO認証の登場、からより実用的なパスキー認証へ
みたいな経緯ですね。
最近の世の中の反応を見ると「多要素認証もだめらしいし、パスキー最強っていうけど評判が」みたいな感覚があると思います。既存の認証方式の課題解決を図った結果、新しい方式が使われるようになり、さらにその課題解決を…の繰り返しの最中であることを意識すると現状もわりとしっくりくるでしょう。「この認証方式はこういう仕組みで、こういう攻撃にやられる」観点で整理をしていくと銀の弾丸なんて...と絶望していくわけですが、重要なのはその根本にある「この脅威への対策として」の部分を意識することです。
現状はさらに悲惨、セキュリティを語るのは認証のレイヤーだけでは不十分
みたいなことを以下の記事に書いています。
オールレンジ攻撃でやられっぱなしに見えてしまいますが、こういう時は「どんな脅威に対してどのような方法で対応していくか」を繰り返し考え、被害が一定の割合以下になるまで繰り返すことでしょう。
認証部分の話にフォーカスすると、前述の資料のとおり今話題の多要素認証の必須化はパスワードリスト攻撃など、リモートの非同期でガンガンやられる攻撃をまず防ぎましょうという施策としないと辻褄が合いません。
そうすると、AiTMといったリモートかつこちらのアクションと同期して動く仕組みでログインセッションをとりにくる攻撃が出てきますというかすでにあるようですね。 これらは現状の多要素認証では一部(セキュリティキーなど)を除いて対策になりません。攻撃者側がよりこっち中心の攻撃に変わるのか、サービス側がここを意識したのテコ入れが行われるのかどうかに注目してみていきましょう。
仮にここでパスキーが普及したとしても、今度はリモートではなくローカル(端末操作しているユーザーの近くにいる、とか物理的にデバイスを奪いにくる)な環境における攻撃にシフトするかもしれません。これをやれば安全！と言い切ることが難しいのが悩ましいところですが、全体を俯瞰しつつ今とれる最良の方法を選択できるように今後も考えていきましょう。
GWに勉強する時間がある人もない人も、今回紹介した資料を見てもろて、既存の認証方式の特徴を意識してもらえたら良いのではないでしょうか。 ではまた。
証券サービスの騒動から考える、サービスが意識しておきたい3層のセキュリティ
ritouです。
話題になったのは少し前ですが、証券会社のサービスを狙った攻撃が報じられました。
規模など考えるととにかく大変そうです。が、起こったことはわりと普通のサービス悪用の話です。
自分達がやってるサービスに同じようなことが起こらないためにも、ざっくりこの辺りは意識しておきましょうというのを書いておきます。
攻撃側の視点で考える
表題に3層って書いたのはこの辺りからです。攻撃者が成し遂げたいもの、そのために何が必要かを考えましょう。
- お金を受け取る、市場を操作できるような動きをさせるなど、最終的に意図した取引が完了すればOK - オレオレ詐欺とかAPP詐欺とか呼ばれてるものなど
- ターゲットとしてログイン状態になって取引ができればOK - 取引パスワード、ログインセッションの奪取
- ターゲットとしてログインするための情報、取引するための情報を取得できればOK - フィッシングなどで静的なパスワード類を奪取
悪い人たちには、他人に決済してもらって商品を手にいれる、お金を振り込ませるといった最終的なGOALがあるわけです。電話をかけてうまく言いくるめてアプリなどを操作させてそれが実現できたら、一番楽です。 昔は電話でATMまで連れてって、そこから...だったものが今はアプリの操作で完結するかもしれません。サービス側として、何より操作しているのが本人だというのが事後対応含めて色々厄介そうですよね。
それができなくて攻撃者自らその取引処理を行う必要がある場合、セッションと取引に関する情報を狙うはずです。紹介した記事で出ていたインフォスティーラーなどでぶっこ抜くことができれば試合終了です。
それができない場合、リアルタイムフィッシングみたいな手法を用いてログインセッション奪取を狙うはずです。証券系のサービスはパスワード認証がまだまだ使われている、かつ取引パスワードなるものも静的なものが多いと聞いたのでフィッシングが大きな脅威となったのだと推測できます。
3層のセキュリティ
脅威を整理した上で、対策を考えましょう。
- お金を受け取る、市場を操作できるような動きをさせるなど、最終的に意図した取引が完了すればOK - 取引状況の監視、同業サービス間の情報共有など
- ターゲットとしてログイン状態になって取引ができればOK - 取引パスワード、ログインセッションの奪取 - ログインセッション保護を含めたセッション管理機能の強化
- ターゲットとしてログインするための情報、取引するための情報を取得できればOK - フィッシング耐性のあるログイン方法やリスク判定、他に穴を残さないID管理機能
1番目、これはサービスのドメインの中での不正利用対策をしっかりしましょうということ ですね。仕事でID+決済の基盤をくっつけて色々やってると、決済部分での制約がここにかかってくるのでわりとイメージしやすいところです。サービス内での挙動の解析、リスク判定みたいなところはAIの使い所でもあるでしょう。IDの分野でも同業者同士で情報を共有する仕組みが出てきていたりしますので、サービスドメインの中でもそのような動きが起こるかもしれませんね。
2番目、3番目はID基盤側が頑張る機能です。やっていきましょう。
2番目はセッションを盗まれないようにしようって話です。今のHTTP Cookieは文字列を別の環境に持っていってHTTPヘッダにつけてやればログイン状態が再現してしまうでしょう。認証認可の世界ではこういうのをBearer(ベアラー) Tokenと呼んだりします。それに対して、特定の環境からしか使えない送信者を制限する仕組みとしてSender-Constrained Tokenと呼ばれているものがあります。今回はそれをHTTP Cookieとかにも必要だよねというところです。
この辺りで、ブラウザが頑張っている仕組みがあります。Device Bound Session Credentials(DBSC)と呼ばれており、ブラウザに秘密鍵を安全に保持しつつそれとセッションクッキーを紐付ける「有効期間の短い認証 Cookie 」なるものを発行します。詳しくは以下の記事を参照ください。
最後のはまさにパスキーだったりで認証機能を強化しつつ、その周囲のアカウントリカバリーなどを含めて強化する話ですね。ここはいくらでもかけますが長くなるので省略します。基本的なところから武装を強化しておきましょう。
まとめ
今回の事案はパスワード系だけではなくセッションまでいかれたっぽいのと、最終的に行われたことにも注目が集まったことでID機能含めたサービス全体でのセキュリティを考えるきっかけになると考えられます。細かい話は置いておいても、セキュリティの話になった時はこの3層ぐらいは意識しておきましょう。
ではまた！
Eメールマジックリンク方式は単体でのログインやパスキーのリセットには向いてない
ritouです。
ソフトウェアデザインのあたりから認証方式の変遷みたいな記事や発表してきた結果、今の形のメールリンク方式は認証方式としては出来が悪いので推せないなという感じになったという記事を書いている。いつ公開するかは未定である。
— 👹秋田の猫🐱 (@ritou) 2025年4月19日
誰かに何か言われそうですね。
認証方式としてのマジックリンク方式と今回の主張
パスキーのすべて ──導入・UX設計・実装：書籍案内｜技術評論社 の1.3ではマジックリンク方式に触れられています。(そして今週末、輪読会の対象でもあります。)
パスキー周りをフィッシング耐性という観点で整理したホワイトペーパー(Passkeys The Journey to Prevent Phishing Attacks | Passkey Central)でも認証方式として紹介されています。
私自身も過去にマジックリンク方式については考察しています。
個人的にはこの方式はなかなかクセが強く、 ログイン方法としての採用できるサービスを選ぶもの だと思っています。
だいぶ控えめな表現でやってきましたが、今回はこれまでより少し強火にして 「現状のマジックリンク方式は、パスワードレスを実現するための認証方式として、またパスキー認証におけるパスキー再設定フローには向いてないと思う」 と言うものです。
それではいきましょう。
パスワードリセットには問題ない
Eメールマジックリンク方式の使い所としては、パスワード認証のパスワードリセットフローでの利用でしょう。 理由として、このパスワード認証のパスワードリセットフローの要件としては、"身元確認さえできれば良い" だったから です。
パスワードは記憶するものだという前提であるパスワード認証において、パスワードの再設定を行う環境というのはどこでもいい わけです。 なので、Eメールを受信した環境でURLを開いてしまうという特徴があまり問題になりません。 もちろんリセットした後にすぐログインしたい、パスワードマネージャーを使っているなど、再設定をする環境に要件がないわけではないのですが、最終的に人力によるコピペという技もあるのでなんとかなってきたというところでしょう。
パスワード認証のパスワードリセットフローとしてのEメールマジックリンク方式はOK です。
次に、単体でログインに利用する パスワードレスな認証方式 としてはどうかを見ていきます。
パスワードレスな認証方式として致命的な導線の課題
これまでは 特徴を完全に理解する人ならば他の認証方式よりもフィッシングのリスクが軽減できて良き みたいな扱いをしていました。PCのブラウザからログインを試みてメールソフトでURLを受け取った場合など、わかってる人ならコピーアンドペーストと言われる技術を駆使して元の環境でログインすることもできなくはありません。
ただ、これがデバイスを跨いだ場合などは話が変わるでしょう。
PC環境でログインしようとする→メール送ったって言われる→モバイル端末でリンク開く→ログイン状態になった！が、ここどこよ。→戻ってもうPC環境で一回ログインしようとする→...(繰り返し)
さすがに厳しいですよね。きっとSNSで文句を言われてしまいます。 これでは単体のパスワードレスな認証方式としては使い物にならないでしょう。
次にパスキーのリカバリーフローへの適用についても考えます。
同じ理由でパスキーのリカバリーフローにも適していない
もう全部書いてしまいましたが、導線が定まらないという課題はパスキーのリカバリーフローへの採用にも影響があります。 先ほど "パスワードマネージャーを使っているなど、再設定をする環境に要件がないわけではない" と書きました。 パスキーのリカバリーフローで行われることとしては次の2点です。
- 身元確認を行う
- パスキーを再登録できる
というものです。もちろんMacOSとiOSなモバイル端末の組み合わせなど、同期されている範囲内であれば問題がない状況にもなり得るものの、ログインしたい環境でパスキーの再設定をしたいという要件はパスワード認証とは異なり無視できないものでしょう。 導線がとっ散らかってしまう課題は後者の要件を満たせないので、しょうがなく登録済みのパスキーを全解除するみたいな落とし所にしたりするわけですが、それは本来のあるべき姿ではないでしょう。
これまでは「パスキーのリカバリーも、まずはこれまで同様のEメールマジックリンクなどで」みたいな話をしたことがありますが、今後はもう少し説明のしかたを変える必要があるかもしれません。
おまけ:フィッシング！フィッシング耐性の話でワンチャン
必ずメールを開いたユーザーがサービスの正規のURLにアクセスしてログイン状態にできる、この特徴は魅力的です。 フィッシングサイトにアクセスさせられたとしても、マジックリンクをメールソフトで受信後は正規ユーザーの環境です。 これをフィッシング耐性と呼ぶ気持ちも分からんでもないですが、単純に導線がとっ散らかった副作用なのでは と思ってしまいます。
あとは、「メールで送られてきたURLにはアクセスしないように」みたいな啓発とのコンフリクトですね。広告メールなどとは異なり、Eメールマジックリンク方式はアクセスしないとログインできません。実装する立場になった瞬間ダブルスタンダードみたいになるのでやはりなんとかしたいです。
Eメールマジックリンクの未来
Eメールマジックリンクが使われる世界を考えてみます。 自分の記事のように、リンクでダメな時用にOTPをつけたりポーリングで元の環境をログイン状態にするとなると、フィッシング耐性を語れなくなります。が、普通にログインできないよりはマシだと思います。
別のアプローチとして想像できるのは、MS Authenticator的な専用の認証アプリやいわゆる母艦アプリを使う仕組みです。 ログインしようとする環境とは別にあるアプリに通知なりQRなりで誘導してログインを行う、Decoupled Authenticationみたいなやつですね。 このような認証フローでは、どちらの環境も同じユーザーが使っていることを確認できる必要があります。パスキーはBLEで近接を取りますが、より一般的なのは数字合わせみたいなやつです。
この辺りを意識して、Eメールマジックリンクを開いた環境を "インストール不要な簡易的な認証アプリ" みたいに使うのは一つのアイディアかなと思います。
まとめ
現状の ”Eメールマジックリンク方式” について自分なりの整理をしてみました。
- パスワードリセットの用途としてはOK
- 導線が定まらない問題は単体の認証方式、パスキーのリカバリーにはNG
- 生き残るなら少し進化が必要そうで、Decoupled Authenticationみたいな方向性が良いのでは
IETFとかで標準化されたりすると有識者が叩いて落とし所が見つかるものですが、そうではないものを使う場合はよく考え(られる人なり猫なりを用意し)ましょう。
ではまた。
嫌われないパスキー実装を探求する - 日経IDのパスキー実装を見てみた
ritou です。
前回、こんな記事を書きました。まず読んでみてください。
パスキー対応をするにあたり、パスキーを使いたい人が普通に使える のは当たり前ですし、どのサービスもそこはそれなりに実装するものです。 ただ、実際にユーザーに使ってもらうとなった時、パスキーが使えない状況だとかパスキーを使いたくないユーザーが不満を覚えてしまうことが先行サービスへの反応からわかってきています。そこで、一歩踏み込んた観点を整理したというのが前回の記事の内容です。
今回からは、この観点でいろんなサービスのパスキー対応を見ていきたいと思います。 どこから見ていくのかというところですが、最近対応がアナウンスされていた日経IDのパスキー対応を見てみます。
日経IDのパスキー対応内容
日経IDのパスキー対応ってどんな感じなの？というところで、昨年末のアドカレで紹介されていた内容から変わってなさそうです。
開発者目線でパスキーのことを考えたことがある場合は上記記事から対応内容が見て取れると思います。
嫌われる実装になっていないかの考察
3つの機能単位で見ていきます。
- 登録促進
- 管理
- 認証
1. 登録促進
アカウント設定のトップ->セキュリティと辿ると、パスキー未登録の場合は説明が上の方にあります。
ログイン直後に登録を促すパスキープロモーションなどは行なっていないようです。これであれば「パスキー登録しろってうるさい」みたいな反応は出ないでしょう。
その分、実際に登録してくれるユーザーの数はなかなか増えない(意識高い系のみ登録してくれる)という状況は考えられますが、そこは今後は頻度などを考えて実装してもらえたら良さそうですね。
2. 管理
管理については基本を押さえた実装になっているように見受けられます。
セッション管理との絡みとかいくらでも細けぇ改善などもできる余地はありますが、プラクティスとして出てきたら対応してもらえば良いでしょう。
3. 認証
ここが本番です。
- パスキー未登録ユーザー×パスキー認証
- パスキー未登録ユーザー×パスキー以外の認証
- パスキー登録済みユーザー×パスキー認証
- パスキー登録済みユーザー×パスキー以外の認証
それぞれ見ていきましょう。
1. パスキー未登録ユーザー×パスキー認証
これは パスキー未登録ユーザーがパスキー認証のフローに迷い込む余地 の話です。
"パスキーでログイン" リンクが見えます。Autofill非対応環境への配慮ですね。 ユーザーの責任とも言ってしまえばそれまでですが、これを誤って押してしまいなんなんだ？となるケースは一定ある ことを意識しておきましょう。 ダイアログにモバイル端末とかセキュリティキーとか出てきちゃうのに我々は慣れていますが、そうではないユーザーの方が大多数だということです。 開発者としてはなるべくパスキー認証させたいんや！というところですが、個人的には Autofill非対応環境はパスキー非対応環境 ぐらいで割り切ってもいいかなと思います。
2. パスキー未登録ユーザー×パスキー以外の認証
パスワード未登録ユーザーがメールアドレスを入力すると、ユーザーの識別とパスキーの登録状態がチェックされた結果、パスワード入力フォームが表示されます。パスワードマネージャーにパスワードが保存されていてそれを選択する場合も、パスワード入力フォームに自動入力されます。これは特に問題なさそうです。
3. パスキー登録済みユーザー×パスキー認証
Autofill対応環境であればしれっとログインできます。
Autofill非対応環境でも、リンクからパスキー認証のダイアログに続けられます。 手元の端末にパスキーがない場合でも、Hybrid Transportによりゴリ押しは可能です。
Autofillでメールアドレスを入力して続けた場合も、ユーザーの識別とパスキーの登録状態がチェックされた結果パスキー認証を促されます。
このボタンからはallowCredentialsに値が指定されます。パスキー使わせたいという気持ちが伝わってきます。
このような実装が問題になり得るのは 手元にパスキーがなく、Hybrid Transportも使えない ようなケースですね。 嫌われるランキング第一位のエラーである "パスキーがありません" が発動する可能性があります。 これは、Identifier-Firstと呼ばれる実装パターンの特徴と上記のワンボタンログインの特徴の合わせ技、というか落とし穴というかそんなところです。
もちろんパスワード認証へのリンクもあるのでどん詰まりにはなりませんが、一般ユーザーにとっては "エラーを見せたら負け" なところもあるので反応などを見て改善などを考えてみてもよいのではないでしょうか。 この辺りで参考になりそうなのはやはりマネーフォワード IDのログインフローでしょう。
- Autofill付きのメアド入力フォーム
- Autofill付きのパスワード入力フォーム(allowCredentialsあり)
と多段でAutofillを仕掛けつつ、パスワード認証へのフォールバックも自然にできるようにするのが現状のベストプラクティスでしょう。
4. パスキー登録済みユーザー×パスキー以外の認証
ここではさらに2パターンを確認します。
- パスキー対応環境だがパスワード認証を使いたい
- パスキー非対応環境
パスキー対応環境でユーザーがパスワード認証を選択するケースから見てみます。 手元にパスキーがない状態はどうしても考えられるわけで、その時にメールアドレス入力フォームのAutofillではパスワードを選択できる場合があります。 パスキー登録済みユーザーが最初のAutofillでパスワードの項目を選択しても、日経IDではパスキー認証を求められます。
これは結局ユーザー識別とパスキーの登録状態を確認してその後の処理を判断するためですが、気になるのは "ユーザーはパスワード認証を選んだ" にも関わらず、"パスキー認証が要求される" ということです。そこからパスワード認証に進むにはワンクリックが必要なのです。 パスキー認証を優先したいという思想から来ているのだと思いますが、これがどういう反応をもたらすのかは少し気になりますね。
改善策としてはこちらもマネーフォワード IDがやっているhiddenなパスワードフォームといったものがあります(どんだけベストプラクティスの塊なんだ)。参考にしても良いかもしれませんね。
最後に、非対応環境も見てみましょう。
日経IDはパスキー非対応環境でもユーザー識別とパスキーの登録有無を判断してパスキー認証を要求するように見えます。そしてボタンを押しても何も起こらない。繰り返しになりますが、パスワード認証へのリンクはあってもユーザーに混乱を与えてしまうことは避けたいですね。 改善案としてはメールアドレス入力フォームの表示の時点などで環境をチェックし、それも踏まえてどの認証を要求するかを決める方が良いかもしれません。Yahoo! JAPANなどはそうしてますね。
まとめ
嫌われないための観点から日経IDの挙動を確認しました。 色々細けぇ話を書きましたが、パスキーを使いたいユーザーにとっては問題なく使えるでしょう。 パスワードを使いたいケース、パスキーが使えないケースで一手間かかってしまう点にどのような反応が出てくるかに注目してもらえたら良さそうです。
別のサービスについても見ていきたいと思います。自分のところも。
告知
3月末はパスキー祭りと言っても良いでしょう。
まずは前回に引き続き iddance です。
次の日の昼には私がお話しします。
記事を書いてる時点では265人ですって。Findyさんの集客力すごいですね。
ではまた。
"ユーザーに嫌われないパスキー実装" の観点 & イベント告知
ritouです。
先にイベント告知：「iddance Lesson.5 パスキーのすべて」
3/24(月)の夜に「パスキーのすべて」著者の3人をお呼びして、本に書いてあることやないことまでお聞きするイベントを予定しています。 他の勉強会ではなかなか聞けない深いお話ができたらと思っていますので、是非本を購入して内容を読み込んだ上で臨んでいただければと思います。
日頃からXで色々言ってて仲が良いんだか悪いんだかわからない、私とくらさんの会話にでも注目しておいてください。
秋田の猫さんとのプロレs…ディスカッションがみれると思うのでぜひご参加を🤼#パスキーのすべて https://t.co/kirfiCg0pC
— kura (@kura_lab) 2025年2月23日
嫌われないための観点
昨年末ぐらいから特に、あるサービスがパスキー対応しました！となった時に、ユーザーに嫌われない実装になっていないかどうかを考える用になりました。
今回はこういう観点も持っておく必要があるのではないか、という整理をします。
対象は "強制ではなく任意でパスキー認証を提供" というところです。
パスキー関連の機能でまずは次の3つに注目します。
- 登録促進
- 管理
- 認証
それぞれ見ていきましょう。
1. 登録促進
パスキー対応を行ったサービスは、当然ユーザーに積極的に利用してもらおうと登録促進の施策を考えます。 代表的なものは次の2つでしょう。
- アカウント設定画面に導線を置きつつ、ユーザーの意思で設定させる : パスキーの説明など、既に出されているガイドラインなどに沿っているか
- パスキープロモーションと呼ばれる、"パスキー登録しないか？" と言う画面を出す : 画面内の説明、画面を出すタイミング、環境は適切か
基本的にユーザーはサービスを利用するために新規登録や認証を強いられます。特に後者のパスキープロモーションについて、各サービスで今の所は受け入れられているように見えますが、あまりしつこく出すとうざがられてしまうことも考えられます。
登録促進については特に "基本を抑えつつ邪魔しない" 誘導が重要でしょう。 今年さらに対応が進むと思われる(期待している)自動登録のあたりも今後関わってくるので、注目しておきましょう。
管理
アカウント設定からの管理のあたりの話です。様々なサービスで汎用的に実装できる部分だと言えるでしょう。 "パスキーカード" といった表現や提示する情報など、ガイドラインを参考にして実装していくことが重要です。
今後はパスワードマネージャーとサービスが保持するパスキー情報の整合性を保つ仕組みであるWebAuthn Signal APIの活用もこの辺りに関わってくるので注目ですね。
認証
ここからはサービス毎に実装に多様性が現れる部分なので、少し細分化して考える必要があります。 まずは認証を行うユーザーの状態を2つに分けます。
- パスキー未登録
- パスキー登録済み
それらが試みる認証フローも2つを想定します。
- パスキー認証
- パスワード認証(+α)のように、パスキー以外の認証
ここまでの組み合わせは4種類になります。
- パスキー未登録ユーザー×パスキー認証
- パスキー未登録ユーザー×パスキー以外の認証
- パスキー登録済みユーザー×パスキー認証
- パスキー登録済みユーザー×パスキー以外の認証
それぞれを見ていきましょう。
1. パスキー未登録ユーザー×パスキー認証
一見、このパターン存在しなくない？と思いがちです。が、認証フローに入ることはありますよね。
- "ワンボタンログイン"
- ユーザーを識別していない状態でのAutofillの "別のパスキーを利用する" みたいなところから
可能性としては圧倒的に前者の方が多いでしょう。そして認証フローに入ったら当然ながら、絶対に成功しません。 意図せずパスキー認証フローに入ってしまい、謎のダイアログ、セキュリティキーやらQRコードとかのワードが出てきたら混乱してしまうでしょう。
例えば、開発者としては "Autofillに非対応、もしくはなんか挙動が怪しい環境" において "パスキー登録済みユーザー" のために "パスキーでログインボタン"を置きたくなります。しかし、未登録ユーザーもクリックしてしまうことはあり得るし、混乱を招いてしまう可能性があることは意識しておきましょう。
2. パスキー未登録ユーザー×パスキー以外の認証
開発者としてはパスキー対応にあたってパスキーを登録したユーザーの利便性をあげたい！と思うでしょう。 しかし、パスキー対応をした時点でユーザーは全員パスキー未登録です。ログアウト状態の未登録ユーザーは必ずパスキー以外の認証を利用する必要があるわけです。
パスキー未登録ユーザーの認証フローがパスキー対応前よりも複雑になったり面倒になったりすると、パスキーに触れる前に "なんか急にめんどくさい" と言う印象を持たれる可能性があるので、意識しておきましょう。
3. パスキー登録済みユーザー×パスキー認証
これは開発者として最優先で考えられる部分ですね。新しい話はなさそうな気はするものの、パスキー認証を優先するかどうかの話は少しありそうです。 よくあるのがメールアドレスなどから識別を行った上で、パスキー登録済みユーザーに対してパスキー認証を要求するという "Identifier-Firstパターン" です。
"パスキー認証が利用可能な環境" において、パスキー認証を要求されたらはいよろこんでとばかりに認証して終わりです。
一方、何らかの事情でパスキー認証が利用不可能な環境があります。具体的には、次の2つです。
- パスキー非対応環境
- ユーザーが登録済みのパスキーにどうしても辿り着けない環境
前者の場合にパスキー認証へと誘導しても成功しません。環境判定はしっかりやりましょう。 そして、環境判定をしっかりしていても、後者のような状況はあり得ます。スマートフォンにのみパスキーが管理されている場合はまだいいとして、PCでしか管理されていない状態からの新規ログイン時には "パスキー認証できねぇ" となってしまいます。
この辺りを考慮した上で、Identifier-Firstパターンにするとしてもメールアドレス入力フォームにAutofillを導入して "パスキー認証が利用可能なユーザー" はそこから認証してもらう、それ以外はパスキー認証を必ずしも望んでいないケースがあるので、パスキー認証をどこまで優先させるかをよく考えましょう。
4. パスキー登録済みユーザー×パスキー以外の認証
上の話と繋がるのですが、パスキー認証が利用不可能な場合は別の認証方式を利用せざるを得ません。
特にIdentifier-Firstパターンのメールアドレス入力フォームにて、パスキーのAutofillを導入することで、これまで単なる "メールアドレスのサジェスト" だったものが "利用したいアカウントと認証方式"の選択に意味合いが変わる場合があります。
これまでパスワード認証を利用していた場合、候補として "アカウントとパスワード認証" が出てきますし、これを選んだユーザーはパスキーではなくパスワード認証を選択したと言う可能性が高いわけです。このようなユーザーに対して、パスキー認証を優先して要求してしまうと、"ここのログインではパスキーが使えないんや。パスワードを使わせてくれ" といった反応をされそうです。こういう場合、マネーフォワード IDのようにパスワードを受け取った場合でも柔軟に対応できるようにしておくのが現状のベストプラクティスな気がしています。
ユーザーの事情でパスキー認証が使えないケースにおいて、開発者としては "パスキー認証を優先しつつフォールバックを用意している状況ならば問題ない" と考えがちです。そして、"こういう仕様です" として内部でQAなどを進めると、動作確認をする方も前提としておいてしまうので "エラーが出ると混乱するのではないか？" といった意見が出にくい状態にもなってしまうでしょう。前述のように成功しないパスキー認証フローに入ってしまうことや、"利用できるパスキーが存在しません" と言う悪魔のエラーを表示してしまうと高い確率で嫌われてしまうことが先行実装したサービスへの反応からわかっているので、ユーザーの意図とは異なる認証方式を要求することになっていないかをよく考える必要があるでしょう。
まとめ
今回は、こう言う状況でユーザーは混乱してしまうのではないか、と言うのを想像しながらパスキー関連機能で気をつける点を整理しました。 これだけが全てという話ではなく、こういう観点もあるのではないか？というところで参考にして貰えばと思います。
今回の観点から実際のサービスのパスキー対応を見ていく、というのも次回の記事でやってみましょう。
繰り返しになりますが、"iddance Lesson.5 パスキーのすべて" への参加登録をお願いします。
ではまた。
ログイン機能でマジックリンク方式の採用を考える際のポイント
ritou です。
いわゆるマジックリンク方式ってのは「メールなどで推測困難なURLを送ってクリックさせたらあれこれする」ものです。 最近のパスワードレスを目指す風潮の中で、様々な人がこの方式をログインに利用することを検討したり話題に出したりしています。
個人的にはこの方式はなかなかクセが強く、 ログイン方法としての採用できるサービスを選ぶもの だと思っています。 今回は、このような検討の際にどの辺を意識したらいいかについて整理しましょう。
最近の関連記事
最近はこんな記事が出ていました。
マジックリンク方式を唯一のログイン方法に使うべきではない4つの理由 ですね。
- 複数デバイスでの利用
- リンク送信時の遅延
- モバイルアプリのあたりの使い勝手
- 仕事用端末で個人用のメールにアクセスする必要が出てきたりしそう
みたいな理由でパスキー認証を使えやという主張です。最後のは必ずしも混ぜるな危険にならない使い方はある気がしますが、概ね同意です。
その続きのように、自分のマジックリンク方式に対してのお気持ち、そしてマジックリンク方式とパスキー認証の組み合わせみたいなとこに触れている記事が出ていました。
この記事で +1 したい部分は 「Passkey Autofillを使ってメアド入力フォームでパスキー認証を利用可能にする、使えない場合でも既存の認証方式にフォールバックできる」 ってところで、ログイン方法としてのマジックリンク方式の考察はそんなにでもないです。
そして、この記事で参照されている404の記事ですね。
マジックリンクは完全ではないことは知ってる、けどパスワードは絶対使わないマン です。
全体を見ると、 パスワード認証やめてマジックリンク方式、そこからパスキー認証を導入する流れについての考察 というところでしょう。
自分の考えともそんなに変わりませんが、ここで今一度マジックリンク方式の特徴、ログイン機能との相性みたいなところを整理してみましょう。
特徴
今回はこの辺りに注目します。
- 利用対象
- 導線
- 外部ネットワークの利用による遅延や障害
- フィッシング耐性
利用対象
当然ですが、サービスがリンクを送信する方法、つまりEmail/SMSなどが利用可能であることが条件となります。 Emailは一般的と言えますし、既存の認証方式に比べて対象者を制限してしまうことはないでしょう。 SMSでリンクを送るとなると、これまでライトな複数アカウント対策などで使われていたようにSIMを準備できる環境という制限があること、送受信に伴う費用についても考慮は必要です。
導線(動線か?わからん)
この方式でログインできるのは、最終的にメールを読んでリンクをクリックした環境になります。
デバイスレベルで言うと
- スマートフォンを利用していて、同一スマートフォン内のメールアプリを使っている
- スマートフォンを利用していて、別のスマートフォンやPCで動作するメールソフトやWebメールを使っている
- パソコンを利用していて、同一PCで動作するメールソフトやWebメールを使っている
- PCのブラウザやソフトを利用していて、スマートフォンや別のPCで動作するメールソフトやWebメールを使っている
となり、さらにリンクをクリックする挙動としても
- Webメールでクリックしてそのままブラウザで開く
- メールソフト、メールアプリ内で開く
- URLをコピペして...
というところで、なかなかのバリエーションが出てきます。これが良いか悪いかの判断について、提供するサービスの特性の考慮が必要です。
- サービスの多数派ユーザーが上記のどのケースに当てはまるのか
- リンクが開かれた場所とログインしたい環境が一致するのかどうか
- 一致しない場合、どのようにフォールバックするのが適切か
などを見極める必要があります。
外部ネットワークの利用による遅延や障害
これは英語の記事と同じですね。届かなかったり遅れたりします。
フィッシング耐性
この方式では、最終的にアクセスするのはサービスの正規のURLとなります。
攻撃者としては、そのURLをユーザから共有してもらえたら、それを使って攻撃者のパスキー登録できる状態になる。 が、通常のログインにおいて、URLをフォームに入力するとか、不自然すぎるからなのか、みたことない。 Emailだったら、HTML mailにしたらURLは簡単に取れないし、さらに難しくなるだろね。
最後のリンククリックの際に正規のURLとなるところで、シンプルにパスワードを奪いにくるレガシーなフィッシング攻撃、URLだけ違うリアルタイムなフィッシング攻撃がそれだけでは通用しないよねという話です。
この辺の過激派としての意見としては、世の中のより広義のフィッシング対策の 怪しいメールのリンクはクリックしない という啓蒙と、この送られてきたメールのURLをクリックするというお作法の相性が気になります。 個人的には別の方法に変えていく必要がありそうですが、難しいところです。
ログイン機能との相性
パスワードリセットとの相性
ログイン機能との相性を考える前に、パスワードリセット機能においてマジックリンク方式が採用されてきました。これはなぜでしょうか？ それは、パスワードを再設定したい環境とログインしたい環境が必ずしも一致する必要がない ためです。
一般的なパスワードリセット機能は 身元確認 と パスワードの再設定 によって構成されます。
メールを受信したことを持ってユーザーとみなす ことが身元確認であり、そのURLから パスワードの再設定 を行うというのが自然に出来上がったわけです。 サービスによって、上記の処理に加えてログイン状態にしたりもします。
特にこれまではパスワードは 記憶する 前提でした。推測困難、サービスごとに別、正規のサービスのみに入力する という要件を人類が満たせるとは思いませんが、できる場合は「パスワードの再設定」を行う環境に制限はなくなります。 これが、幅広く利用されてきた理由と言えるでしょう。
しかし、今後はどうでしょうか。いつも言っているように、人類はパスワードを記憶するのではなく信頼するシステムに任せることが重要であり、パスキーもその延長です。 ユーザーが登録できるパスワードは一つなのが一般的です。パスワードマネージャーを利用しているユーザーは、いつものパスワードマネージャーが動作もしくは同期する環境で パスワードの再設定 を必要とします。 これを考えるとマジックリンク方式との相性はこれまでよりも悪くなる可能性もある気がしています。
新規登録、ログイン機能との相性
新規登録機能についての考え方はパスワードリセットと似ています。
一般的な新規登録機能は 身元確認 と パスワードの設定 によって構成されるのでそこまでは一緒です。
メールを受信する環境と新規登録したい環境の違い については次のような設計、実装があります。
- マジックリンクをクリックした環境で登録処理を完了させ、元々使いたい環境では一度ログインして使わせたらOK
- 裏で状態管理とかポーリングの仕組みを用意しておき、マジックリンクをクリックした環境で登録処理を完了したら元々使おうとした環境が「登録完了するの待ってるね」から「ログイン状態」にする
ログイン機能についてはより、メールを受信する環境とログインしたい環境の違い が無視できません。 そして、新規登録と同様に マジックリンク方式を使いつつログインしようとした環境をログイン状態にしたらいいじゃないか というわけでもありません。 それをしてしまうと、通知を受けた認証アプリで「ログインする」というボタンをクリックすることでログイン状態にする方式に寄っていき、フィッシング耐性のところで触れた特徴がひっくり返ってリアルタイムなフィッシング攻撃に弱い方法となってしまいます。
英語の記事では色々書いていましたが、やはりこの環境の違いを考慮することが一番重要だと思います。 統合IDや認証基盤といったところになると、それを使うサービスの特性がこの辺りの判断に影響します。 個人的にはログイン方法としてはマジックリンク方式の採用を避けるお気持ちになることが多いです。
マジックリンク方式とメールOTPのハイブリッドな方式
話は少し逸れますが、マジックリンク方式とメールOTPのハイブリッドな方式ってもあります。しかも結構前から。 こちらは頼まれてもいないのにリリース直後の他社サービスの新規登録/ログイン機能を解説した記事です。
(最近は見てないので当時の)bosyuでは、ブラウザの環境(PC/Mobile)によって、マジックリンク方式なのかOTPとのハイブリッドなのかを判断しているように見えました。 環境が異なるときはURLをコピペさせる案内もしています。クロスデバイスやモバイルアプリの利用についても、この辺りはよく考えられた設計といえます。マジックリンク方式を早い段階で採用したmediumもこんなだった気がしましたが、忘れました。 当然、考慮しなければいけないことも増えるわけですが、頭の中で マジックリンク方式はこういうフローで、ダメならやり直し だけではなく組み合わせるという柔軟さは持っていたいところです。
まとめ
まとめです。
- 最近、パスキー絡みでマジックリンク方式のログインについて書かれることが増えてきた
- 特徴を見ると、やはり認証フローを開始した環境とメールを受信する環境の違いの部分が重要
- パスワードリセット、新規登録、ログインという代表的な機能との相性を見ていくと、ログインとの相性が良くないと判断されるケースが一番多そう
- メールOTPとのハイブリッドな方式の採用例もある
検討時のポイントを書いたつもりが自分が採用しない理由になっている気がしますが、やはりUXは重要です。
開発者観点ではつい こうすればできる を考えてしまいがちですが、様々な状況が考えられる中で ユーザーがうまくやる ことを前提にするのはとても危険な思考であることはこれまでの状況を見てわかるはずです。 パスキー認証と同様、認証方式においては 大多数のユーザーが特に意識せず、あまり頑張らずに使える方法 を用意することが重要です。 要は個別具体で考えるしかないおじさん と言ってしまうとそれまでですが、この辺りを考える際は意識しておきましょう。
ではまた。
認証方式のフォールバック/リカバリー方法の選定において考慮すべきユーザーの状態
ritouです。
kokukumaさんがパスキーのリカバリーについて考察されていました。
サービスがパスキーを利用 -> フィッシング耐性を必要とする前提において
- 複数の認証方式を利用可能にしておいてフォールバック
- ユーザー自身でできるリカバリー
- CS問い合わせ
を用意する際にどう考えたらいいかが整理されています。
フォールバック、リカバリーの基本的な概念について自分が書いた記事を読んで貰えば、少し理解が進むと思います。
今回は、このように検討されて提供されるフォールバック/リカバリーの仕組みが適切なのかどうかの判断においてもう一つ重要となる、これが必要となった際のユーザーの状態を考えてみます。
当然ながら、これはパスキーに限った話ではありません。
考慮すべきユーザーの状態
ユーザーの状態を考えるにあたり「あるサービスをユーザーがどの環境で利用しているか」を意識しましょう。当然ながら、サービスの提供スタイルによって
- (1つ|複数)のPCから利用
- (1つ|複数)のモバイル端末から利用
- (1つ|複数)のPCと(1つ|複数)のモバイル端末で利用
といった状況が考えられます。
例えばモバイルアプリのみで提供されるmixi2であれば(1つ|複数)のモバイル端末で利用、 LINEのようにモバイルアプリケーションは1つに制限されているが(複数の)PCからも利用可能といった違いがあります。メルカリはどうでしたっけ？
当然、そのようなサービスを利用するユーザーの利用スタイルも
- (1つ|複数)のPCを利用
- (1つ|複数)のモバイル端末を利用
- (1つ|複数)のPCと(1つ|複数)のモバイル端末を利用
と様々になるわけです。
ここから、一番クリティカルな状況と考えられる「モバイル端末が(全て)利用できなくなった」状態ではどうなるのかに注目します。
「モバイル端末が(全て)利用できなくなった」らどうなるのか
いわゆる所持情報を利用する認証方法やリカバリー方法のうち、モバイル端末に依存するものがいくつかあり、今後も増えることが考えられます。 スマートフォンを紛失、盗難、故障などで手元で利用できなくなった場合、その時点で利用できなくなるものがあります。
- SMS OTP
- キャリアメールを用いたEmail OTP/Link
- 回線認証
- モバイル端末に保存されたリカバリーコード
- モバイル端末にインストールされたアプリによるポチ
- 今後出てくるDigital Identity Wallet関係も?
これらの内訳となると、一時的に使えないものと恒久的に使えないものがあります。
- 一時的なもの
- キャリアのアカウントやプラットフォーム、3rd Party Password Managerのアカウントに関連するもの
- ログイン済み/設定済みのモバイル端末を利用するもの
- 恒久的なもの
- 個々の端末にしかデータがないもの
前者は新しい端末にアカウントを設定することで復活することができますが、どれぐらいの期間で元通りになるかは個別に事情が変わるでしょう。 キャリアのアカウントの認証自体が理想的とは言えない状況ではショップに身分証を持ち込む方が早いかもしれません。 プラットフォームアカウントについても、同一プラットフォームの別端末の有無などによって違いが出ることがあります。 3rd partyのパスワードマネージャーなどでは認証に既存のデバイスを利用するものもあります。それが失った場合はリカバリーに時間がかかることはあり得ます。
後者はパスキー以前のFIDOクレデンシャルの話と同じです。 Digital Identity Walletに保存されたVCの扱いはこの辺りどうなるのでしょうか？動向にも注目ですね。
サービス側としては、自身が提供するサービスにおいてモバイル端末が利用できない状況において
- 他の認証方法もまとめて使えなくならないか
- リカバリー方法も使えなくならないか
- 復旧に時間がかかる場合も「C2Cの購入が完了しているので発送手続きを進めなければならない」といった状況を問い合わせ対応などで回避できるか
といったところを確認しておく必要があるでしょう。
PC端末が利用できなくなる場合
単純に「連絡先へのコンタクト」に関する機能が異なるため、モバイル端末に比べるとPC端末が利用できなくなり困ることが少ないかもしれません。
モバイル端末をつかってPC向けのサービスにログインする設計のほうが逆よりも多いので、対称ではありません。
依存対象の分離
この文脈で注目したいのは、最初に取り上げたkokukumaさんの記事で「デジタル認証アプリを使ったリカバリ」です。 マイナンバーカードを利用する仕組みは、モバイル端末への依存が少なく、わりと多くのユーザーが取得していることが期待でき、セルフリカバリーとして利用可能です。
UX面ではモバイル端末で完結するものよりも複雑になってしまうものの、このような依存対象の異なる仕組みは有用です。
まとめ
今回はユーザー側の観点に立ち、モバイル端末が利用できなくなる場合にどうなるかに注目しました。
モバイル端末に依存する仕組みが増えると、それが利用できなくなったときにいくら認証方式を多重化しリカバリー方法を用意してもまとめて利用できない状況に陥る可能性があります。
設計、実装した段階では大丈夫だろうと思っていても、問い合わせで気づくこともありますね。モバイル端末に情報が集約する流れを否定するわけではないですが、その前提の上でトラブルに強いサービスを提供したいですね。
ではまた！
効率的な管理よりもまず使う！複数登録可能という特徴を活かしたパスキー利用法
ritouです。
今日は26日ですが、Digital Identity技術勉強会 #iddance Advent Calendar 2024 13日目の記事です。
今回は、複数環境から利用するサービスに対して超積極的にパスキーを使っていくスタイルの紹介です。 みんながこれをすべきという話ではなく、こういう使い方をすると何が良くなるのか、逆に懸念はないのかと言うのを考えて貰えばそれで十分です。
パスキーは複数登録可能
今日、えーじさんがパスキーの現状、そしてユーザー、サービスそれぞれができることについて記事を書かれていました。自分の記事とは違って読みやすい文章です。
この記事では、この部分に注目します。
複数のパスキープロバイダにパスキーを作る
サービスによりますが、パスキーは本来、アカウントごとに複数作ることができるようにデザインされています。Google パスワードマネージャーと iCloud キーチェーンなど、複数のパスキープロバイダを跨いで複数のパスキーを作ることで、パスキーが見つからない場合のトラブルをだいぶ減らすことができます。誤ってパスキーを消してしまっても、他のパスキーを使って復旧することができます。
パスワードに代わるものと言われていることでイメージしにくいかもしれませんが、パスキーは複数登録可能です。導入サービスのほとんどがそうなっています。えーじさんの記事では選択肢を増やすことで”パスキーが見つからない"となる確率を下げるための"コツ"の一つとして紹介されています。
「パスキーが利用可能な環境であれば片っ端から登録する」と言う使い方
パスキー認証を導入していてパスキー認証以外の認証方式も利用可能なサービスにて「パスキーが見つからない 」となった際、以前から設定していた多要素認証を利用してログインすることになるでしょう。
今回紹介するのは「パスキー認証以外でログイン成功したら、そこでパスキーを登録して今後はパスキー認証を使っていく」と言うものです。
図にするとこんな感じですね。あんまり意味ないです。
ここで登録するパスキーの保存場所(パスワードマネージャー、パスキープロバイダ)は、その環境におけるデフォルトのもので十分です。
仮に利用可能なパスキーが存在する場合、登録時に「もう登録されとるぞ」って言われるかもしれません。それはそれで良かったと言うことですね。
期待できる効果
このお作法をすることにより期待できる効果は次のようになります。
- 一度利用した環境では次回以降パスキー認証が利用可能
- 最初に利用したのが「パスワード認証のみ」であれば、今後の「パスワード認証のみ」の試行回数を減らすことによる安全性の向上
- 最初に利用したのがパスワード認証＋αの多要素認証であれば、今後の(パスキー認証による)フィッシング耐性の獲得と利便性の向上
この文脈ではあくまで副次的な効果として、モバイル端末のプラットフォームがデフォルトで提供するパスワードマネージャーを使うと、今後「クロスデバイス認証」を利用できるようになる、と言うのもあります。
パスキー登録をしまくって問題は起こらないのか
一番の懸念は、パスキーの登録可能な数に制限がんるとそれに引っ掛かるかもしれないと言う点です。 自分のところでは最大5個に設定してあって、これぐらいあれば大丈夫かなと言うところでしたが、サービスによって違うかもしれません。
どんどん新しい端末やブラウザでパスキーを登録したけど、ログインできる環境が増えることで今度はそれが悪用されないか心配、と言う考えを持つこともあるでしょう。その端末自体を掌握されてしまうとその可能性はありえますし、パスキー認証においてその部分は「ローカル認証で他のアプリなどと同様のレベルで守る」というのが前提になっているとも言えます。
とはいえ残っているのは気持ち悪いので、サービス側の管理機能から不要になったパスキーを削除/無効化するのが良いでしょう。そのパスキーでは今後ログインできなくなります。
OAuthが普及し、API提供側でやらかしが起こった時に「連携サービスを見直す」と言う習慣が少し出てきたと思います。 パスキー認証が普及してきたら定期的にこの辺りを見直す習慣についても広めていきたいですね。
パスキーを登録した端末が壊れてしまったらどうするのか
上述の通り副次的な効果はあるとして、基本的にはどんどん新しい端末でパスキーを使っていくというだけの話なので使えなくなった場合についてはなんとも言えません。(追記: パスキー認証でないとログインできない状態ではなく、パスキー以外の方法でもログインできることを前提としています。それはパスキー認証"自体"の話ではないので触れません) 紛失などの場合はサービス側の管理機能から削除/無効化しておきましょう。
サービスは推奨すべきか
これは「すべきではない」でしょう。
現在、パスキー認証をサポートするサービスが行っているパスキープロモーションの条件は「パスキーを登録していないユーザー」と言うものが多いかと思いますが、これを「この環境でパスキーを登録/利用していないユーザー」となるとユーザーに対する圧が強すぎます。
これを色んなサービスでやるのは大変！
それはそうですね。異論ありません。世の中のサービス全部にこれをやるとなると、ユーザーの負荷はとても大きいです。 そもそもこの使い方、パスキーがFIDOクレデンシャル/FIDO2クレデンシャル、パスキー認証がFIDO認証とか呼ばれていた頃のプラクティスと言えます。パスキーが同期されることで、このような毎度の登録が省略できるわけですが、えーじさんの記事にもあるとおりまだまだ同期できないケースはあります。そんな中で、自身でパスキー認証の頻度を上げるための取り組みといえます。
対象の選定で言うと、今回の方法が効果的となるのは次のような場合でしょう。
- 複数環境から利用するサービス
- 個別の環境毎でみた時に、ログインする機会の多いサービス(セッションが短い、決済などがあって再認証を要求される)
- ID連携のIdPをしているようなサービス
こんなサービスはそうそうなさそうですが自分の中で「このサービスだけはパスキー優先でいきたい」と言うのがあったらやってみても良いでしょう。
まとめ
あるサービスに対してパスキーを複数登録可能という特性に注目し、「使える環境では登録する」と言う利用スタイルを提案してみました。
多くのサービスはパスキー認証のみ利用可能にはなっていません。この状況はしばらく続くでしょう。 「自分のパスキーが同期していないが、パスキーが利用可能な環境であれば都度登録して使っていく」と言う利用方法により、なるべくパスキー認証の利用頻度を増やし、他の認証方式を使ってフィッシング被害に遭うことを減らす効果につながったら良いなと思います。
ではまた！
パスワード、パスキー、生体認証...どんなユーザー認証にも"詰み"はあり得る
ritouです。
最近何度かパスキー関連の記事を書いていて、こんなコメントをいただくことが増えてきました。
”もちろんパスキーでも詰んでしまうことはあり得るのですが” そこだよな
”パスキーでも詰んでしまうことはあり得る“話にならん、何言ってんだ？リカバリ方法のないそんなもん使おうと思う訳あらへん。
別件ではパスワード認証が詰まないと書かれているのも見かけましたので、一回整理しておきましょう。
「どんな認証方式でも、詰む」
パスワード、メールやSMS OTP、メールで送られるマジックリンク、認証用アプリ、TOTP、生体認証、パスキー...全ての認証方式で「詰む」状況というのはあり得ます。
- 知識情報 : 忘れる
- 所持情報 : デバイスや環境をなくす、一時的に利用できない
- 生体情報 : 関連する器官の欠損、怪我など
もちろん、その頻度や条件が異なります。
FIDO認証からパスキーに変わった部分でも、あまりにも「詰む」可能性が大きいために実用的ではないねとなっていたところをパスワードマネージャーの同期を利用して改善しようという流れになったわけで、そのパスワードマネージャーにアクセスできなくなったり、同期している端末全てにアクセスできないなど詰む状況はあり得ます。
ソーシャルログインでも同じです。 OpenID Connectの啓蒙をしてきた中でも、「GoogleアカウントがBANされたらどうするんだ」「一時的にGoogleが使えない状況だったら」と指摘を受けまくってきました。
パスワード認証はもっとも詰みやすい方式と言えるでしょう。 詰んでいるので「パスワードを忘れた方はこちら」からメールアドレス入力画面へと遷移してリカバリーフローに入るのです。
- 個々の認証方式には必ず「詰みポイント」が存在する
- サービス側はその可能性などを踏まえて複数の認証方式を用意して当人認証をなんとか成功させられるようにしたり、身元確認してクレデンシャルの再設定を行うリカバリーフローや問い合わせ対応の仕組みを用意しています
なぜパスキーのリカバリーに注目が集まるのか
この辺りはパスキーの導入パターンと関係しています。
- 利便性観点 : 既存のパスワード認証 + 追加認証と同等の扱いとして導入
- (利便性に加えての)安全性観点 : ログインや特定機能の保護のためにパスキー認証のみに対応する形で導入、利用できない場合は問い合わせして本人確認
前者はパスキー認証を使うことで「便利に使える手段を増やす」ことを実現できます。一方で「最低の認証強度は変わらない」「別の方法でフィッシングにやられるかも」「パスワード認証を無効化できないなら意味ない」と言った反応をもらうこともあります。
後者は認証強度やAAL/IALと言った概念を導入し、一定の基準を超えるものだけを選択肢とする設計です。 パスキー認証で詰む条件とその後に求められるリカバリーフローの要件(フィッシング耐性やAAL/IALの設定)がある場合、ユーザーに課せられる負荷が高くなってしまうことがあり得ます。
サービスはパスキー認証を導入することで何を得たいのか、どのようなユーザーを保護するのかをよく検討し、ユーザーにとって高いハードルとならないための設計が必要となります。
現状はこの辺りを意識しているサービス、していないサービスそれぞれが存在しているので必ずしも良い印象を持たれていないと考えられます。 それぞれ「詰む」可能性のある認証方式とリカバリーフローをうまい具合に組み合わせて、ユーザーから見たときに「詰みにくい」認証フローを実現していく必要があります。
まとめ
- 全ての認証方式が詰む。パスキーも詰むし、ID連携でさえも詰む。パスワードはもっと詰む
- 「利便性向上」と「利便性+安全性の向上」どちらに重きを置くかという判断で導入パターンが変わり、前者より後者の難易度が高い
- サービス開発者は自サービスの特徴、ユーザーの利用形態などを踏まえた上で全体として「詰みにくい」フローを実現する必要がある
以上です。
この記事をDigital Identity技術勉強会 #iddance Advent Calendar 2024 5日目の記事として、終わりたいと思います。
ではまた！
