パスキーとID連携の認証フローの共通点から見る認証技術の基本
ritou です。
少し前にパスキーとID連携の関係を考えるときにこういう観点があるよという話をしずかな方に書きました。
今回は、ログインに利用しようとした時のフローの中でここ似ているよね、こんな意図があるんだよっていう部分を取り上げます。
認証フローの似ている点
登場人物をUserAgent、RP、Authenticatorとして、あらゆるところを簡略化したシーケンスを用意しました。
ID連携、いわゆるソーシャルログインでは次のようになります。
登場人物をUserAgent、RP、IdPとするとこんな感じでしょう。
もちろん細かいところは違うわけですが、全体の流れは似ています。
WebAuthnのchallenge, OIDCのnonce, state
先ほどのシーケンス、たまたま似ていると言うよりも、これは認証フローにおける基本の流れであると意識しておきましょう。
パスキーやID連携の実装に触れたことのある方は次のパラメータの扱いについて考えたことがあると思います。
- WebAuthnにおけるchallenge
- OIDCにおけるnonce(やstate)
いずれの値も認証フローが始まる際にRPが生成しセッションに紐付けて保存し、Authenticator/IdPから受け取った結果の検証にそれを利用します。具体的に言うと、認証要求とセッションを紐づけておき、認証結果とセッションの紐付けを検証することでCSRF対策ができます。また、データストアとの組み合わせなどでワンタイムの値とすることでリプレイ攻撃にも対策できます。この辺りは認証方式を考える人たちにとっては想定できる攻撃への対策なので、標準化されたプロトコル自体に含まれているんだよと言うのはおさえておくと良いでしょう。
「ん？でもSAMLにはIdP Initiatedなんとかってのがあるな」みたいなことを思った方はこちらの記事でも読んでおいてください。
他の認証方式で言うとパスワード認証やSMSやEmailを経由したOTP、バックアップコードの確認などでも同様のフローが適用できるはずです。サービスとユーザーしか出てこない仕組みなのでこんなのいらんやろと思うかもしれませんが、古のWebアプリケーションフレームワークではHTMLフォームにCSRFProtectionTokenみたいなのついてきたりしますよね。あーゆーのも目的はセッションとのバインドであり既知の攻撃への対策です。Emailでリンクを送信するマジックリンクはちょっと癖がある感じでしょうけれども。
まとめ
いくつかの認証方式を触っていると、似ている使われ方だけど名前が違うパラメータが出てきたりします。
仕様策定が行われている団体やメンバーが違ったりするので完全に一致する方が奇跡なんだろうと思います。
ここのプロトコルでこのパラメータはこの役割で使われると言うのを理解した上で、全体を俯瞰してこの脅威に対してこの対策が取られている、このプロトコルのこのパラメータはこっちのこれに相当する、みたいなところまで意識できると安全な認証機能の実装や評価に繋げられると思います。
ではまた。
Discussion