ID管理機能のもう一つの軸として、セッションライフサイクルを意識しよう
ritouです。
Digital Identity技術勉強会 #iddance Advent Calendar 2025の12/11の記事です。
会員サービスを提供するにあたり必要となるID管理機能について、重要な考え方としてユーザーIDの状態と状態遷移を表現するアイデンティティライフサイクル(Identity Lifecycle)というものがあります。
ユーザーがとりうる状態(未登録、登録済み、サスペンドなど)とその遷移にあたる処理(登録、一時的な無効化、退会など)を意識することで、どの機能を実装すべきかの検討に役立つでしょう。
しかし、ID管理にはこれに関連しない機能がいくつかあります。 例えばログイン、ログアウトなどはユーザーの状態と無関係ではないものの、状態遷移にあたるものではありません。 これらの機能はいわゆるセッション管理に関するものであるため、別の軸としてセッションライフサイクルのようなものがあったら実装する必要のある機能を意識できるのではないか というのがこの記事の趣旨となります。
この内容はどこかのドキュメントに書かれているものではなく考えてみた程度なので、ご了承ください。
セッションライフサイクル(仮)
今回の話は、単一サービスにおけるセッション管理を想定します。 最もベーシックなクライアント-サーバ構成でセッション情報にアクセスすることを目的とします。
状態と遷移はこんな感じです。
状態は次の5つです。
- 未発行: いわゆる未ログイン状態
- 有効: ログイン状態
- 要変更: ログイン状態ではあるものの、セッション情報と実際のユーザーの情報に差異があること(セッションCookieやトークンにJWTを用いている場合などで起こりうる)
- 無効: クライアント側はCookieなりトークンといったデータを持っているが、サーバー側でセッションを無効にされている
- 紛失: サーバー側のセッションは有効であるが、クライアント側にそれに紐づくデータが存在しない
状態遷移は次のようになります。
- 未発行 -> 有効: ログイン
- 有効 -> 未発行: ログアウト
- 有効 -> 有効: 再ログイン
- 有効 -> 要変更: アカウント情報の変更
- 要変更 -> 有効: 再認証 or 情報更新
- 有効 -> 紛失: クライアント側のデータ削除
- 紛失 -> 未発行: サーバー側の無効化
- 有効 -> 無効: サーバー側でセッション情報の無効化
- 無効 -> 未発行: クライアント側のデータ削除
むかーしむかしから、セッション管理の安全な設計ってどんななのかみたいな話が続いており、JWTだと失効管理がががみたいなことがよく語られます。 その辺りも丸っと含め、セッション管理に必要な機能って？と考えた時のコアな部分はこの状態遷移に含まれていると考えます。
- ログイン
- ログアウト
- クライアント側データの情報更新(必要ならば)
- 無効なセッションに紐づくクライアント側データの削除
- 利用されていないセッション情報の手動/自動削除
漠然と考えていた内容を整理してみた段階なので過不足もある気がしていますが、こういう考え方もできそうだなというところで意識してもらえたらと思います。
なんとなくですが、ID連携でも同様の整理ができるかもしれません。引き続き考えていきましょう。
ではまた！
「OAuthは認可、OIDCは認証」という説明が人によりブレる理由とより理解を深めるために必要な考え方
ritou です。
一日遅れましたが、アドカレ最終日の記事です。
一個誰かが忘れてる以外は埋まってますね！特に中盤までのAuthlete無双ありがとうございます。
前日(24日)の記事も大作でございました。
今回は巷でよく言われている「OAuthは認可、OIDCは認証」ってフレーズについて整理しましょう。
「OAuthは認可」わかる
OAuthは(最近だと3rdパーティーに関わらず)あるアプリケーションに対して安全なリソースアクセスの提供を実現するための仕様です。 リソースオーナーはそのアプリケーション自身かもしれないし、アプリケーションのユーザーかもしれません。 リソースアクセスを提供する側が認可し、利用する側は認可されてリソースアクセスをします。これは特に問題ないでしょう。
「OIDCは認証」わかる？
OIDCは認証、これはどういう意味かわかりますか？ もしかしたら「ユーザー情報を受け取ったサービスがそれを "認証" に利用するから」みたいな印象かもしれません。 いわゆるソーシャルログインってそういうものですね。それを実現するための仕様がOIDCですよと。
果たしてこれは正しいのでしょうか？
仕様の最初の方を読んでみましょう。
It enables Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner. これにより、クライアントは認証サーバーによる認証に基づいてエンドユーザーの身元を確認できるほか、相互運用可能かつREST的な方法でエンドユーザーに関する基本プロファイル情報を取得できます。
認証する、してるのは誰かというと、認可サーバーです。その結果を提供(なので認可サーバー側はIdentity Providerと呼ばれる)することでRPは身元を確認できるとありますね。RPはそれを利用して "認証する" なんて実は書いてないのです。
そのあとは仕様の関係について触れられていて、OAuthでは上記のユーザー情報の提供のための仕様が存在しないので足してるって感じです。
Notably, without profiling OAuth 2.0, it is incapable of providing information about the authentication of an End-User. 特に、OAuth 2.0 はプロファイリングを行わない限り、エンドユーザーの認証に関する情報を提供することができません
この辺りはOAuth認証()の話。
OpenID Connect implements authentication as an extension to the OAuth 2.0 authorization process. OpenID Connectは、OAuth 2.0認可プロセスの拡張として認証を実装します。
この一文は微妙な表現ですね。こいつのせいかもしれん。
まとめ
「OAuthは認可、OIDCは認証」の真意(?)とは、
「OAuthは認可、OIDCは(IdPが)認証(したユーザーの情報をやり取りするための仕様)」
って思っておくのが良いでしょう。
もしかしたら、これまで監修して責任はワイにあるなんて言ってきたAuth屋さんの本で違う言い方してるかもしれません。 ちょっと細かいこと忘れてしまったので、持ってない方は買ってもろて、年末年始に全冊確認して下さい。
「認証認可」というキーワードから一歩進むために必要な考え方と宣伝
上記のOIDCの部分をもうちょいしっかり説明しようと思うと、次のような前提知識が必要となります。
- サービスはそれぞれID管理を行っており、Identity Registerによるアイデンティティ情報の管理、Identity Lifecycleを意識した機能(新規登録やアカウントリカバリー、退会など)とSession Lifecycleを意識した機能(ログイン、ログアウトなど)を実装している。
- いわゆる本人確認と呼ばれる機能は次の2つのいずれかが行われている
- 身元確認(Identity Proofing): ユーザーが提示した情報をなんらかの方法で検証すること
- 当人認証(Authentication): 正規のユーザーであることを検証すること
- あるサービスのアイデンティティ情報を別のサービスに提供するのがID連携(Identity Federation)
OIDCはID連携のためのプロトコルであり、IdPが自身で管理しているアイデンティティの情報をRPに提供します。 そして、受け取ったRPはそれらを身元確認や当人認証に利用します。 仕様としてはサービス間のデータのやり取りが定められているOAuth 2.0に「アイデンティティ情報をどのように表現するか」といったIdentityレイヤーと呼ばれるものを加えた形となっています。
みたいな感じになります。
==ここから宣伝です。==
このような前提知識はどこに書いてあるのか、1/7に発売予定の私の本に書いてあります。
みんな大好き「認証・認可」と言うフレーズですが、現場の人間が実際に作らないといけないのはそれ以外のあれやこれを含めた「ID管理」の機能です。
— 👹秋田の猫🐱 (@ritou) 2025年12月11日
オンラインサービスのIDを支える機能や概念をXや記事などでいつも言ってるキーワードを使って紹介しているので、是非読んでみてください。 https://t.co/9WGsoTIdBc
ぜひお手に取ってみて下さい。
==宣伝終わり==
ではまた！
メールプロバイダが狙われる！パスワードレス時代の攻撃手法を意識する
ritou です。
今日から12月、アドカレの季節ですね！ということで今年もやっていきましょう。 これは「Digital Identity技術勉強会 #iddance Advent Calendar 2025」一日目の記事となります。
あんまり長くなっても読むの大変なので、短めにします。今日はこちらの話をしましょう。
SBI証券を名乗るなりすましメールによる乗っ取り被害にご注意ください - Yahoo!メール新着情報
個別のURLなのにHTMLのtitleとかが「Yahoo!メール新着情報」なのがじわじわきますね。
この記事はSBI証券を名乗るなりすましメールに関する注意喚起です。 ユーザーがなりすましメール内のリンクから偽サイトに誘導され、認証情報を盗み取られた結果、Yahoo!メールアカウントとSBI証券アカウントの両方が乗っ取られ、不正取引などの被害に遭う可能性がある として、その手口と対策を解説しています。
今回のポイント
次の3点ですね。
- メール受信が必要な機能を、メールプロバイダのアカウントを乗っ取ることで利用可能にする手口が存在
- その実現のためにメールアドレスのプロバイダごとにロジックが存在し、出し分けられている
- 「正規のサービス以外に入力しない」という啓発が行われてきたパスワードに比べ、OTP系は気軽に入力してしまうかも
1点目ですが、パスキー認証の導入が進んではいるものの、依然必須化は難しいというのが現状です。 それに伴い、当人認証のフォールバックや、身元確認の方法としてメール受信を利用するケースは存在するわけですが、今回はその部分をメールプロバイダのアカウントを狙うことで突破したというわけです。一度メールプロバイダのアカウントがやられると同様のメール受信を利用する他のサービスでも利用可能となるため、より気を付ける必要があるでしょう。
2点目は当然ながら、メールプロバイダごとにロジックが用意されていることがわかるわけです。 中間者系のフィッシングサイトでは、フォームに入力された値を中間者として正規のサービスに送るだけの処理を想像してしまいがちですが、実際はよりテクニカルに個々のメールプロバイダに対応もしくは出しわけがされる状態であると認識しておく必要がありそうです。
3点目はユーザーのお気持ち的なところで、パスワードよりもOTPの方がフィッシングサイトに入力されるリスクが高いのかなと思ったりします。「パスワードは正規のサービスのみに入力してください。」という啓発のSMSやEmail OTP版もたくさんやっていく必要があるかもしれません。
今回は簡単ですが、メールプロバイダのアカウントが狙われる！という話をしました。
明日はこいわいさんがパスキーの話を書いてくれそうです！お楽しみに！
それでは、パスキーの世界最高権威を狙う者による怪文書には気をつけましょう
ではまた！
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は重要です。
開発者観点ではつい こうすればできる を考えてしまいがちですが、様々な状況が考えられる中で ユーザーがうまくやる ことを前提にするのはとても危険な思考であることはこれまでの状況を見てわかるはずです。 パスキー認証と同様、認証方式においては 大多数のユーザーが特に意識せず、あまり頑張らずに使える方法 を用意することが重要です。 要は個別具体で考えるしかないおじさん と言ってしまうとそれまでですが、この辺りを考える際は意識しておきましょう。
ではまた。
