2020-12-07

Identity Lifecycleを意識したID管理機能の設計

f:id:ritou:20201207033809j:plain

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

Digital Identity技術勉強会 #iddance Advent Calendar 2020 7日めの記事です。

qiita.com

OIDCとかFIDOとかOAuthとかGNAPとかいろいろな話題の記事が書かれて素晴らしいですね。

今回はID管理の設計の話をしましょう。

ID管理機能、どう作る?

新しいサービスを作る時、必ず必要となるのがID管理機能です。

ID管理！なんていうとエンプラ臭いですが、コンシューマー向けのサービスでも

認証方式どうする？ソーシャルログイン？パスワードレス？自前でパスワード認証...
新規登録ではメアドやSMS確認してパスワード設定させて...
パスワード認証の機能作って...
再認証もできないとダメだし...
メアドやSMS、パスワード変更も必要だ
リスト攻撃怖いから2要素？2段階？できます
リカバリーめんどくさい問題
退会の時、データ消す？残す？
サスペンド機能が欲しい？承知しました

とかいう流れは普通にあるでしょう。

このあたり、漏れなく設計/実装するために、どんなことに気を付けたら良いでしょうか。

~~社内にこの辺得意そうな猫がいたらそれに任せるでいいと思いますが~~ いわゆるWeb Application Frameworkについてくる機能に任せたり、Googleとか有名なサービスを真似してなんとなく作ったりしてるとこも多いのではないでしょうか。

そんなのサービスの本質ではない！今はIDaaSの時代！IDaaSを使え！

という流れもありつつも、IDaaSの選定をするにも必要な機能をちゃんと整理できている必要があるでしょう。今回は、ID管理機能の設計の際に "Identity Lifecycle" というのを意識してみましょう というお話を書きます。

Identity Lifecycle @ ISO/IEC 24760-1

ID管理についての様々な定義が書かれている、ISO - ISO/IEC 24760-1:2019 - IT Security and Privacy — A framework for identity management — Part 1: Terminology and concept というドキュメントに "Identity Lifecycle" が記載されています。

www.iso.org

("The electronic version of this International Standard can be downloaded from the ISO/IEC Information Technology Task Force (ITTF) web site" ってとこから辿れば無料でダウンロードできます。)

"Identity Lifecycle" はB向けC向け関わらず、Identity Systemにおける状態と状態遷移を表現したものです。

f:id:ritou:20201206015413j:plain

5つの状態

f:id:ritou:20201206015424j:plain

ユーザーが取りうる5つの状態が定義されています。

Unknown : 未登録や退会して完全にデータを消去した状態
Established : データはあるけどまだサービスは使えない、仮登録的な状態
Active : 本登録が終わってサービスを利用できる
Suspended : 一時的に利用できない
Archived : データは残っているけどサービスは利用できない、論理削除の退会済み的な状態

これは割と直感的かと思います。

状態遷移

f:id:ritou:20201206015435j:plain

そしてその状態遷移として、いくつかのアクションがあります。仮登録、本登録、登録情報更新、一時利用停止、退会など直感的なものもあれば、C向けサービスだとこれあるかな？と考えてしまうものもいくつかあります。

ID管理機能の設計にどう活かすか

新たに設計を行う際にこれを意識できれば一番良いんでしょうけれども、ある程度設計が進んだ段階で 想定している機能に不足がないかを確認する ぐらいでも良さそうです。

"自サービスでユーザーが取りうる状態" を確認
その状態間で取りうる状態遷移から、機能に不足がないかを確認する

ちょっといくつかのパターンでやってみます。

パスワード認証

パスワード認証を利用しつつSMSやメールでリカバリーできる、一刻も早く滅びて欲しい感じの設計です。

最初にSMS/メールの確認、終わったらパスワードや属性情報登録して利用可能
一時利用停止あり、退会しても一定期間データを残す

みたいな場合、こんな感じになるでしょう。

f:id:ritou:20201206022842j:plain

使わない遷移をオリジナルのやつから削ったりちょっと変えてる部分があります。

それぞれを見ていきましょう。

f:id:ritou:20201206022905j:plain

仮登録的な意味合いでまずメアド/SMSの登録ですね。

最初にパスワードやプロフィール情報の入力も同時にやってからのメアド/SMS確認ならここでしょう。

f:id:ritou:20201206022930j:plain

メアド/SMSを確認してパスワード、プロフィール情報を登録して本登録完了。

f:id:ritou:20201206023015j:plain

メアドやパスワード、プロフィール情報は変更機能も必要です。未ログイン状態からのパスワード変更と捉えると、パスワードリセットもここに含まれるかもしれません。

f:id:ritou:20201206023042j:plain

悪いことをしたり、されたり(不正ログイン)した場合は一時停止の機能が必要ですね。

f:id:ritou:20201206023108j:plain

退会処理も、すぐにデータを消すのではなく一旦 "Archived" な状態にしておいて、やり直しがきくようにします。 (オリジナルのやつと変えて"Restore" のところを "Archived" から "Active" に戻してるのは("Archived" -> "Established" -> "Active") の省略みたいなところです。) そして、一定期間が過ぎたり申告などで全部データを消しますよと。

こんな感じで、一通りの機能をカバーできてるかなと思います。

ソーシャルログイン

Googleでログインとかでさくっと使えるサービスの場合はまたちょっと変わりますね。

IdPから確認済みメアドがもらえたらそれ使う、もしもらえなかったりした場合は個別で確認もできる
退会したら即データ消去。同じIdPのアカウントで再登録したら1からやり直し

みたいな場合、こんな感じになるでしょう。

f:id:ritou:20201207024802j:plain

"Unknown" から "Active" への遷移を増やしたり、"Archived" な状態を消したりしてます。

f:id:ritou:20201207024937j:plain

未登録で確認済みメアドを持ってるIdPのアカウントが来たら即登録完了、これがソーシャルログインの醍醐味でしょう。 (直接の状態遷移でなくても内部で "Established" -> "Active" と遷移してるよ、と捉えても良さそうです)

f:id:ritou:20201207024952j:plain

ざっくりソーシャルログインと言っても、

認証のための識別子 : IdPの識別子 + IdPから受け取ったユーザー識別子
連絡先などの確保 : 確認済みメアド
その他属性情報 : IdPから受け取ったプロフィール情報

と細かく整理できていれば、

IdPから確認済みメアドが受け取れないケースにも対応する
複数IdPに対応しており、同じメアドを受け取った場合に(追加で認証するなどして)既存のアカウントと紐付ける、もしくは別ものとして連絡先を確認するかをユーザーに決めてもらう

みたいなことができます。

実際はあまり見かけませんが、確認済みメアドがなかった場合を仮登録状態として、ここから確認したら登録完了みたいな設計もありでしょう。

f:id:ritou:20201207025008j:plain

なのでこの状態遷移も残しましたよと。

f:id:ritou:20201207025024j:plain

別のIdPのアカウントと紐付け直し、メールアドレスの変更機能が必要ですね。

f:id:ritou:20201207025051j:plain

IdPのアカウント単位でブラックリストに入れたり、IdPから不正利用があったよと通知が来たりしたら一時的な利用停止もあり得るでしょう。

f:id:ritou:20201207025108j:plain

退会でIdPとの紐付けなどのデータをバッサリやっちゃうならここはシンプルになるでしょう。

どうでしょうか。このパターンも一通りカバーできてそうな気はします。

パスワード認証 + 2段階認証

追加認証があっても状態/状態遷移が増えなければパスワード認証の場合と変わらなそうです。

パスワード認証 and/or ソーシャルログイン

取りうる状態/状態遷移が異なる認証方式が組み合わされている場合、当然増えた状態/状態遷移を追加することになるでしょう。

IDaaS利用時にも参考にできる？

機能単位で使っていけるパターンなら、これまで書いてきたような考えを適用してIDaaS側、利用する側でそれぞれ機能が足りているかどうかを確認し、選定時に役立てられるのではと思います。

まとめ

ISO/IEC 24760-1にIdentity Lifecycleと言うものが定義されているよ
ユーザーの取りうる状態、状態遷移を意識することで、設計中/実装済みのID管理機能において不足してる部分がないかを確認できそうだよ

と言うお話でした。

匿名でも質問受け付けております！

marshmallow-qa.com

私のアドカレ次回作は12/15です。

qiita.com

正直そろそろしんどくなってきました！ではまた！

2020-12-01

OAuth認証とは何か?なぜダメなのか - 2020冬

OAuth AdventCalendar Authentication Authorization OIDC

f:id:ritou:20201108013816p:plain

こんばんは。ritouです。

Digital Identity技術勉強会 #iddance Advent Calendar 2020 1日めの記事です。

qiita.com

初日なのでゆるふわな話をしましょう。

何の話か

もうだいぶ前ですね。9月のお話です。こんなTweetを見かけました。

社内Slackにいる「OAuth認証」と書くと訂正してくれるbotが丁寧な解説をするようになっていた
認証(Authentication)と認可(Authorization)は間違えやすいわりにミスると甚大な被害をもたらしがちなので、常日頃から意識を高めていきたいですね pic.twitter.com/oVQxBgZcHS
— greenspa (@greenspa) 2020年9月28日

このbotに対する思うところはもう良いです。

今回は、「OAuthの仕様に沿ってID連携を実装するいわゆる"OAuth認証"の実態に迫り、なぜダメなのか、そして代わりにどんな方法があるのか」 を振り返ります。

(追記)長いので結論から先に

OAuthとOIDCで 目的が違う ことはよく知られている
OAuthのリソースアクセスの仕組みだけを利用してクライアント側がID連携の実装を試みても最低限の要件を満たせず、クライアントの構成によっては認可サーバー、リソースサーバー側の拡張が必要となる場合がある
ID連携のためには「●●でログイン」と言う認証イベントを実施したユーザーの情報を "安全に" やりとりする仕組みが必要
TwitterやGithub, Facebookは安全に利用できるフローを示したり、不足している部分を独自に拡張したりしてOAuth認証を可能にしている
OpenID ConnectではOAuth認証で独自実装になり得る部分を標準化仕様としてサポートしているのでご利用ください

それでは始めましょう。

OAuth認証とは？そもそもOAuthとは？

OAuthは異なるサービス間での「APIアクセスのためのアクセストークンの発行(取得)」や「アクセストークンを用いたAPIアクセス」と言う、APIの保護を目的として標準化された仕様です。

雰囲気でOAuthやっちゃってた勢に人気の本を意識しながら、OAuthの登場人物から振り返ってみましょう。

f:id:ritou:20201127103729j:plain

認可サーバー : アクセストークンを発行するサービス(例:Google アカウント)
リソースサーバー : アクセストークンを利用したリソースアクセスの対象なるサービスで、認可サーバーと一緒でも別でも良いが実際のサービスでは同一サービス内の別機能的な立ち位置が多い。(例:有料化が話題となったGoogle フォト)
クライアント : 認可サーバーからアクセストークンを取得し、リソースサーバーにリソースアクセスを要求するサービス(例:画像編集アプリ)
リソースオーナー : リソースサーバーが提供するリソースの所有者(例:Googleのユーザー)。ユーザーの場合もあるし、クライアント自身がリソースオーナーになるパターンもある。

処理の流れを見ていきます。

f:id:ritou:20201127103748j:plain

クライアント(画像編集アプリ)は認可サーバー(Google アカウント)にリソースサーバー(Google フォト)で管理されているデータへのアクセスを要求
認可サーバーがリソースオーナー(Googleアカウント)を認証し、クライアントへのリソースアクセス許可についての同意を得る
認可サーバーはクライアントにアクセストークンを発行
クライアントは、アクセストークンを用いてリソースサーバーにあるリソースオーナーの画像を返すAPIにアクセスし、取得した画像を編集対象として利用

OAuthの特徴としては

APIはアクセストークンにより保護される
- 3rdパーティーなクライアントでも有効なアクセストークンを持っていたらリソースオーナーの代理としてアクセスOK
認可サーバーがリソースオーナーの認証とアクセストークンの発行を行うため、3rdパーティーなクライアントは直接リソースオーナーのクレデンシャル(パスワードなどの認証に必要な情報)を扱う必要がない。よって安全！

となります。ここまでがOAuthの説明です。

そして、OAuth認証とは、 クライアントが「●●でログイン」のようないわゆるID連携、ソーシャルログインをOAuthの仕組みを利用して実現すること です。

f:id:ritou:20201127103809j:plain

クライアントは認可サーバーに リソースオーナーの情報へのアクセス を要求
認可サーバーがリソースオーナーを認証し、クライアントへのユーザー情報提供についての同意を得る
認可サーバーはクライアントにアクセストークンを発行
クライアントは、アクセストークンを用いてリソースサーバーにあるアクセストークンからリソースオーナーの情報を返すAPIにアクセスし、取得したリソースオーナーの情報に含まれるユーザー識別子など を自サービスの認証に利用する

このような手順を踏むことで、クライアントは認可サーバー/リソースサーバーから 「ログインしようとしたのは誰か」 を知ることができ、自身の認証に利用できるでしょうという考えですね。

何がいけないのか？

たまに 「OAuthは認可の仕組みであり、認証の仕組みではないのでOAuth認証はダメ」 という言い方を目にしますが、もう少し踏み込んで整理しましょう。

ID連携の最低限の要件

「●●でログイン」しようとしたユーザーの識別子を取得する ことはID連携における、最低限の要件です。もっと複雑な用件については後述するとして、ここではOAuthの仕様を利用してその要件を満たす実装ができるのかどうかを確認しましょう。

繰り返しになりますが、OAuth 2.0の最も基本的な仕様では

アクセストークンをこうやって取得できます(RFC 6749)
アクセストークンをこうやって利用できます(RFC 6750)

というのが定義されており、逆にいうとそれしか定義されていません。よって、クライアントがOAuthを用いてID連携をしようと思うと

「●●でログイン」しようとしたリソースオーナーのアクセストークン を取得しよう
アクセストークンを使ってプロフィールAPIなどからユーザー識別子を取得して認証に利用しよう

という考えになるわけです。

(認可サーバーがアクセストークンと一緒にユーザー識別子を返すような実装も見かけましたが、拡張となるので今回はおいておきます。)

アクセストークンの役割とのミスマッチ

ここで、”OAuth認証" を用いたWebアプリケーションのID連携でよくある実装を例示します。 よく知られているOAuth 2.0の認可コードフロー を利用します。

f:id:ritou:20201128231132j:plain

Webアプリであるクライアントがサーバサイドのライブラリなどでアクセストークンを取得する
リソースサーバーにあるプロフィールAPIからリソースオーナーの情報を取得する
取得したリソースオーナーのユーザー識別子を用いて認証する

この流れを安全に実装することは、可能です。

OAuth 1.0であったり、OAuth 2.0の「認可コードフロー」を用いたアクセストークン取得までの一連の流れで 「●●でログイン」しようとしたリソースオーナーのアクセストークンであること が担保される
アクセストークン取得後にリソースアクセスを行い、 「●●でログイン」しようとしたリソースオーナーのユーザー識別子であること が担保される

と言うことで、「●●でログイン」しようとしたリソースオーナー の情報をハンドリングできる場合は問題ありません。

次に、クライアントはモバイルアプリとバックエンドサーバーで構成されている場合の実装を例示します。

f:id:ritou:20201128231146j:plain

モバイルアプリがSDKなどでアクセストークンを取得する
モバイルアプリはバックエンドサーバーにアクセストークンを送信
バックエンドサーバーはリソースサーバーにあるプロフィールAPIからリソースオーナーの情報を取得する
バックエンドサーバーは取得したリソースオーナーのユーザー識別子を用いて認証する

(これ以外に 「モバイルアプリ」はただのリダイレクタとなり「バックエンドサーバー」がアクセストークンを取得し、プロフィールAPIにアクセスする という実装も考えられますが、OAuth 2.0ベースの仕組みだと割と一般的にモバイルアプリケーションやSPAなどでアクセストークンの取得まで可能なSDKが用意されている場合が多く、そこから拡張しやすい上記の例のような実装を見かけることが多いため取り上げました)

先ほどのフローにモバイルアプリとバックエンドサーバーのやりとりが紛れ込んだだけなので問題なさそうに思える実装ですが、まさにそのモバイルアプリとバックエンドサーバーのやりとりにおいて、「●●でログイン」しようとしたリソースオーナーのアクセストークンであること」 が担保されなくなります。

具体的には、第3者によって次のようなアクセストークンがバックエンドサーバーに送られる可能性があります。

別のクライアントに対して発行されたアクセストークン
同一クライアントを利用する別のユーザーに対して発行されたアクセストークン

RFC6750で定義されているOAuth 2.0のBearer Tokenの仕組みが利用されている場合、リソースサーバーはリクエストに指定されたアクセストークンが有効であればレスポンスを返します。

このような構成において、「●●でログイン」しようとしたリソースオーナーであること」をアクセストークンだけで担保することはできるのでしょうか？

OAuthにおいてアクセストークンの役割は

リソースオーナーは誰か
リソースオーナーの代わりにアクセスするクライアントは誰か
どのリソースにアクセスできるか
いつまで有効か

ぐらいの情報を リソースサーバー が理解し、リソースアクセスの要求の検証、リソースアクセスのレスポンス生成に利用することです。 JWT形式のアクセストークンとかいう仕様もありますが、基本的にはクライアントに情報を伝えるためのものではない ため、クライアントがこれらの情報を取得するためには、リソースサーバーがプロフィールAPIもしくはアクセストークンに紐づけられた情報を返す専用のAPIとして提供する必要があります。このAPIのレスポンスを検証することで、 "別のクライアントに対して発行されたアクセストークン" であることを検知可能です。

しかし、"同一クライアントを利用する別のユーザーに対して発行されたアクセストークン" を検知することは困難です。

これを検知するためには「クライアントのどのセッションと紐づいているか」という部分を認可サーバー側がアクセストークンに紐づけておき、さらにAPIとして提供する必要があります。

このようにクライアントだけではなく認可サーバー、リソースサーバーも独自拡張などの工夫が必要となることから、ID連携の最低限の要件でもOAuthにおけるアクセストークンによりカバーできる範囲を超えたものであり、OAuthの仕様を独自に拡張するなどの対応が必要です。

複雑な要件への対応

繰り返しになりますが、ここまで紹介してきた 「ユーザー識別子が取れたら認証に利用できる」 という要件、これはあくまでID連携を最低限の要件と言えます。

実際に異なるサービス間のID連携を考えていくと、いくらでも要件が出てきます。例えば、様々なサービスが多要素認証を導入している中でID連携を行う際に、ID連携と自サービスで認証を要求するタイミングや認証強度を揃えたい場合もあるでしょう。

クライアントからの認証要求
- 多要素認証必須で頼む
- 多要素認証したかどうか、方法の連絡を頼む
- このリソースオーナーに対して再認証を頼む

みたいな要件が出てくることもあるでしょうし、よりサービス同士が密なユースケースでは

セッション関連の要求
- 自動でセッション同期させたい
- 手動でセッション同期してるか確認したい
- 一緒にログアウトさせたい

みたいなセッションに関する話も出てくるかもしれません。

認可サーバー上でのリソースオーナーの認証処理 について、OAuthではノータッチですし、クライアントが認証処理を行った後の認可サーバー-クライアントのセッション管理 についても当然触れられていません。これらを実現するためには、またまた認可サーバー、クライアントの両方が独自で拡張する必要があるでしょう。

オレオレプロフィールAPI

ここまでの流れで "OAuth認証" には リソースオーナーの情報を返すプロフィールAPIが必要 でした。しかし、OAuthで定義されているのはAPIアクセスのリクエスト/レスポンスヘッダぐらいであり、このようなユーザー識別子を含むリソースオーナーの情報のやりとりは定義されていません。

今までも様々な仕様でユーザー識別子、メールアドレス、電話番号などを返す標準化されたAPIが定義されてきましたが、その仕様策定における思惑ってものがあるのです。わかりますよね？

標準化の隙間が引き起こす事態

上記の複雑な要件への対応や独自のプロフィールAPIについて、標準化されていない状態のままでは各サービスが似て非なる実装を行ったりして互換性のないID連携方法の乱立を引き起こします。(現実は標準化された仕様があってもなかなか足並み揃わなかったりしますけどもなかったらもっとカオス)

某OmniAuthなどのようにそこを吸収するライブラリで解決するという方法もありますが、そもそも標準化されたOAuthを使ってる意味が...ってなってきますし、最悪の場合は脆弱性を作り込んでしまう場合があります。

そんなに面倒なら "OAuth認証" を使わせてるサービスはどうしてるの？

例として、TwitterはOAuth 1.0ベース、GitHubやFacebookはOAuth 2.0ベースでID連携の仕組みを提供(認可サーバー、リソースサーバー側)しています。Twitterはサービスの規模からもはやTwitter認証として居座っていますし、GitHubは開発者が使うサービスが多いので実装する側も割と意識して作っている印象です。

FacebookはOAuth 2.0以前からFacebook Connectと題してID連携の仕組みを提供しておりそれ自身がOAuth 2.0のベースとなった経緯もあり、上記の課題についても独自路線を貫いていますが、新たにOAuth認証を提供したいサービスが真似しようとしてももはや無理なところまで行っちゃってます。

このような大きなサービスであれば監視の目も多く、脆弱な点についての指摘が行われ、常々対応されていく感じですがそこまでの規模ではないサービスがOAuth認証の認可サーバー、リソースサーバーをなんとなく実装すると逆に指摘されるタイミングが遅れ、脆弱な点が残る可能性もあるでしょう。

ID連携を目的としたプロトコル

ここからは、"OAuth認証" と比較されがちな、最初からID連携を目的としたプロトコルについて見ていきましょう。

OpenID Connect : OAuth 2.0がID連携のために進化したぞ！OAuth 2.0で定義されているAPI保護の仕組みに ID連携に必要な機能を追加したプロトコルです。
SAML : エンタープライズで実績抜群！XMLだしプロトコルの詳細はめんどいんだけどそれを埋めるプロダクトもたくさんあるので要は金で解決できるやーつ

~~大人の事情により~~ ここではOpenID Connectについて上記の課題にどう対応しているかを整理します。

OpenID Connect はどうなのか

ここからは上記の "OAuth認証" が持つ課題について、OpenID Connectがどう解決するかを紹介します。用語は OAuth 2.0 あたりのものを利用します。

"認証イベントの情報" をIDトークンとしてやりとり

OpenID Connectではアクセストークンとは別に、IDトークンというものを発行します。

IDトークンには

誰が : リソースオーナーの識別子 "sub"
いつ : リソースオーナーが自身の情報へのアクセスに同意した日時 "iat"
どこで : 認可サーバーの識別子 "iss"
誰に : クライアントの識別子 "aud", "azp"
どれぐらいのリソースに対して : アクセス対象となるユーザー情報の範囲 "scope"

と言った「●●でログイン」しようとしたイベントに関する情報、さらに

リプレイアタックを防ぐためのクライアントのセッションに紐づく値 "nonce"
リソースオーナーがいつ認証したか、認証方式、どの基準の認証レベルか "acr", "amr"

という値や、

氏名
生年月日
住所
メールアドレス、確認済みかどうか
電話番号、確認済みかどうか

と言った、クライアントが要求したリソースオーナーのプロフィール情報を含められます。

IDトークンは(OAuth認証に欠けている)認証イベントに関する情報を JWT(JSON Web Token) と言う仕組みで署名をつけたり暗号化してクライアントに渡すための仕組みであり、署名検証にいよる改ざん検知、暗号化による情報漏洩対策もやろうと思えばできます。

クライアントはこのIDトークンを用いて、"ログインしようとしたのは誰か" を把握し、認証処理を安全に実装できます。 "●●でログイン" を実現するだけであれば、アクセストークンを用いたAPIアクセスを行う必要もありませんし、モバイルアプリとバックエンドサーバーの構成でもこのIDトークンを用いることで安全に実装できます。

f:id:ritou:20201128234715j:plain

Webアプリなクライアントでは、リソースサーバーへの問い合わせなしで認証処理が可能です。細けぇ話で言うと認可レスポンス(OIDCでは認証レスポンスと呼ぶ)もしくはアクセストークンと共に取得できます。

f:id:ritou:20201128234729j:plain

モバイルアプリ+バックエンドサーバーなクライアントでは、IDトークンを検証することで 「●●でログイン」をしようとしたリソースオーナーであること を担保できます。一連の流れになっていることを担保するために、nonce と言う値が利用できます。このあたりは去年のアドカレで書いた気がするので良かったらどうぞ。

ritou.hatenablog.com

拡張された認可(認証)リクエスト

上記IDトークンで認証イベントの情報を含めるために、認可サーバーへのリクエストも拡張できるようになっています。

認証方式や認証強度を要求したり
メールアドレスや電話番号への個別の情報単位で要求するリソースを表現したり
それらを(リソースオーナー自身でも)改ざんできないようにJWSで署名つきにしたり

と言ったことが可能です。

OAuth 2.0では様々な拡張仕様が検討されており、これらと重複しているものもありますが、 OIDCでは 最低限のものからある程度複雑化した要件を持つID連携に対しても、必要な機能 が定義されています。

よって、OIDCではIDトークンの利用を含めてと合わせてOAuth認証ではできなかった複雑な要件への対応が可能です。

標準化されたUserInfo API

OIDCではプロフィールAPIも定義されています。

OAuth認証ではクライアントがユーザー識別子をぶっこぬいて認証に利用するためのAPIと言う立ち位置でしたが、IDトークンにその用途を譲り、UserInfo APIではプロフィール情報の同期などを目的としてアクセストークンを用いて最新のリソースオーナーの情報を返すAPI として定義されています。

豊富な拡張機能

それ以外も、セッションに関する拡張仕様や最近はよりセキュアな仕組みが求められる金融サービスに対するプロファイル(FAPI)などの仕様策定が続けられています。

いやいや、結局OAuth 2.0への後付けじゃねーの

それはそうです。昔からID連携に求められる要件ってのは決まっている中で、どうやったら新規/既存のサービスに普及するかが重要です。

OpenID も前のバージョンなどでは OAuth と全く別の仕様で実装されてきたものの、最新の仕様であるOpenID ConnectはOAuth 2.0ベースで進められることになりました。

「Identityレイヤーを被せた」などとも表現されますが、OpenID Connectは OAuth 2.0を用いたOAuth認証で標準化が必要な部分を定義した仕様 と言えます。

まとめ

今回は "OAuth認証" について振り返りました。

OAuthのリソースアクセスの仕組みだけを利用してID連携の実装を試みても最低限の要件を満たせず、クライアントの構成によっては認可サーバー、リソースサーバー側の拡張が必要となる場合がある
ID連携のためには「●●でログイン」と言う認証イベントを実施したユーザーの情報を "安全に" やりとりする仕組みが必要
TwitterやGithub, Facebookは安全に利用できるフローを示したり、不足している部分を独自に拡張したりしてOAuth認証を可能にしている
OpenID ConnectではOAuth認証で独自実装になり得る部分を標準化仕様としてサポートしているのでご利用ください

と言うあたりで、開発者はどうすれば良いかと言うと

ID連携を提供したいサービスは OpenID Connect に対応する
- オレオレ実装をする場合は "非互換性" を認識し、リスク分析をした上で、SDKやライブラリ、ドキュメントなどを用意して安全に利用してもらえるようにする
ID連携を利用したいサービスはそのサービスが OpenID Connect に対応しているかどうかを確認する
- オレオレ実装の場合、意図せぬ脆弱性を踏まないように純正SDKやライブラリ、ドキュメントを確認する
- OpenID Connectに対応している場合も、そのサービスがどれぐらい仕様に対応しているかを確認する

てな感じではないでしょうか。

今後も、"OAuth認証" というキーワードを聞くことがあるかと思います。正しい理解を広めて平和な世の中を目指していきましょう。

私のアドカレ次回作は12/7です。ではまた！

qiita.com

ここで質問受け付けてるので気軽にどうぞ！

marshmallow-qa.com

2020-11-15

LINEログインの対応から「手元のスマホでログイン」の仕組みであるDecoupled AuthNを理解しよう

Authentication Decoupled CIBA FIDO LINE

f:id:ritou:20201115074615p:plain

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

何の話か

今日はLINEが発表した取組みと今後使われるようになるかも知れない認証方式について紹介します。

FIDO2使ったout of band認証がまずは、iPad版LINEから提供始まりました。デスクトップ版も準備中。https://t.co/BqFHGCyCuf
— naohisa ichihara (@nao_ichihara) 2020年11月11日

linecorp.com

まず使ってみました。流れはこんな感じです。

f:id:ritou:20201115075009p:plain

電話番号を入力し、"スマートフォンでログイン" ボタンを押します。

f:id:ritou:20201115075041p:plain

初回は認証番号を使う必要があります。

f:id:ritou:20201115075113p:plain

スマホ側では初回は認証番号を入力する画面が出て、入れると生体認証やパターンロックなどが要求されます。

2回目以降は、"私ではない" か "ログイン" というボタンが表示され、生体認証やパターンロックなどが要求されてログインできます。

LINEのようにアプリが多くのユーザーの手元のスマートフォンにインストールされて利用されている場合、それを生かさない手はありません。様々な端末のLINEアプリケーションを "手元のスマホでログイン" してパスワード入力をせずに簡単に利用できるようにする、そのための第一歩が今回の施策であります。

そこで、今回は細かいところで3つの観点から見ていきます。

手元のスマホを使ってログインする "Decoupled Authentication" という仕組み
FIDOの生体認証などと組み合わせることによる利便性の向上
決済など外部サービス間で "Decoupled Authentication" を実現するための標準化仕様

"手元のスマホでログイン" = Decoupled Authentication

ログインしたいサービスが動作する端末とログインに利用する端末が分離されている認証方式のことを "Decoupled Authentication" と呼びます。"Decoupled Flow" などと表現を使っているところもあります。 (誰が呼び始めたのか、定義を昔調べた気がしましたが忘れました。)

"手元のスマホでログイン" と言えば、Googleは早い段階から、Android端末を用いたGoogleアカウントのログイン機能を実装していました。

support.google.com

Googleの対応は2種類の用途があります。

パスワード認証後、2段階認証としてスマホに通知が行ってOKする = 記憶認証(パスワード) + 所持認証
パスワード認証前にメアドを入れた時点でスマホに通知が行ってロック解除してOK = 所持認証 + 記憶 or 生体認証(ロック解除)でパスワードレス！

f:id:ritou:20201021220719p:plain

(OTPの設定をしている場合、前者は2段階目の方法の追加となりますが後者だと2段階認証を解除しつつのこの方法を設定となります。業務で使ってるアカウントの場合は2段階認証必須などのルールとの兼ね合いにお気をつけください。)

パスワードレスな新しい端末だったり、パスワード管理ソフトの設定が済んでない状態で長くて複雑なパスワードを手打ちするのは結構大変です。ブラウザの機能も進化したぶん、一時的に利用する端末にパスワードを覚えさせないような注意も必要かもしれませんが、このパスワードレスの方式であればブラウザがパスワードに関与せずに認証が実現できます。 2段階認証の用途で言っても、PCのブラウザに毎回ワンタイムパスワード用のスマホアプリや受信したSMSを見て手打ちするよりはユーザー体験が良くなるかもしれません。

この方式にも課題はありますが、それは後述します。

金融/決済分野でのユースケース (3-D Secure / Open Banking)

この前、3-D Secureに関する投稿をしましたが、クレカチャージ/決済のための登録時などに使われているクレカ所持者の当人認証でもこのような "Decoupled Authentication" の導入がサポートされていて、3DS Secureの version 2.2 ぐらいから仕様でも関連するパラメータが含まれています。

ブラウザで決済、スマホのアプリに認証要求
サブスクの決済を登録、月単位でスマホのアプリに認証要求

そして日本でも銀行のAPI提供が話題に上がることが増えてきましたが、英国のOpenBankingの技術仕様でも "Decoupled Approach" として言及があります。

standards.openbanking.org.uk

より強度の高い認証が求められる分野の利便性を向上させるための方法として "Decoupled Authentication" に注目が集まっています。

Decoupled Authentication & FIDO(ファイド)

LINEはFIDOアライアンスに参画し、生体認証による利便性向上、パスワードレスに向けた取組みを以前から進めており、今回の対応もスマートフォンで生体認証などを使うことによる利便性を生かす仕組みです。

最近はFIDOの仕様をサポートしながら生体認証に対応するデバイスも増えてきましたが、全ての端末に指紋やら何やらを登録していくのはなかなか手間でしょう。普段使っていない、他人の所有している端末や新しい端末を利用する場合は "手元のスマホ" を利用する "Decoupled Authentication" を使うことでその利便性を向上させられるかもしれません。

FIDOの仕様策定、普及を促進しているFIDOアライアンスでも "Decoupled Authentication" のユースケースが考えられていて、LINEのようにインターナルなユースケースではなく、異なるサービスが絡んだユースケースがドキュメントにまとめられています。

fidoalliance.org

先ほどのOpenBankingのドキュメントと似たようなP(PaymentやProvider)が出てくるキーワードだらけでもはや呪文にしか見えないかもしれませんが、3-D Secureと同様の決済におけるユースケースに触れられております。

f:id:ritou:20201115075451p:plain

上の図にある通り、"決済機能におけるマーチャント"から"アカウントを管理してるサービスのモバイルアプリ"に決済情報が送られ、生体認証をしつつ内容を許諾するとマーチャント側で決済が成功しています。

そのためには、下の図のように "アカウントを管理してるサービスのWebアプリ" と "アカウントを管理してるサービスのモバイルアプリ" の間で事前の設定が必要ですみたいな図です。

このように、"手元のスマホ" でFIDOの生体認証などを行うことで、"Decoupled Authentication" のユースケースの利便性を向上されることが以前から検討されていて、やっと実装される段階になったという感じです。

異なるサービス間でDecoupled Authenticationを実現する仕組み - OIDC CIBA(シーバ)

ところで、FIDOは生体認証の裏側で行われる公開鍵暗号方式を用いた処理を定義しているものです。先ほどの資料ではいわゆる"チャレンジ"の値を引き回してブラウザ-スマホアプリとの連携をしましょうみたいなことは書いてありますが、上の図のMerchant - ASPSP の間の決済情報のやりとりなどは仕様の対象外です。

3-D Secureでは当然、決済の一連の流れが定義されていますが、それとは別のアプローチで標準化が進められている仕様があります。それが OpenID ファウンデーションで仕様策定が進められている OpenID Connect(OIDC) Client Initiated Backchannel Authentication Flow(CIBA) です。

OIDCとは、簡単にいうと外部サービスが "Google でログイン" を実装するための仕組み であり、CIBAはそのOIDCのフローを "Decoupled Authentication" で実装するための仕様 と言えます。

CIBAについて知りたい方は以下のリンクを参考にしてください。

ritou.hatenablog.com

qiita.com

OIDCやOAuthでは、リソースアクセスの権限要求などに加え、サービス間で決済情報などをやりとりする仕組みがあります。しかし、FIDOで定義されていない "サービス間のやりとり" が定義されているCIBAには "手元のスマホでの認証処理" の具体的な部分(パスワード認証とかFIDOとか)について細かく定義されていません。守備範囲が違うけど組み合わせて使えるということで、FIDOとOIDCは、”補完関係”にあたる関係です。

f:id:ritou:20201115075512p:plain

CIBAの仕様自体はそれなりに成熟してきた段階にあり、先ほど紹介した英国OpenBankingのガイドラインでもCIBAを利用するOIDCのプロファイルが参照されています。 "Decoupled Authentication" は標準化仕様の組み合わせにより実装できる状態にあると言えるでしょう。

"Decoupled Authentication" の課題 - UX, フィッシング耐性

ここまでで利便性のことをメインに "Decoupled Authentication" を紹介してきましたが、課題もそれなりにあります。

UX : 利便性を売りにする以上、ブラウザでのユーザー識別のためのメアド入力を減らしたりスマートフォンで行う動作を最小限にするなどのチューニングが必要でしょう。決済でのユースケースでは購入情報などをどこまで引回すかなど、ベストプラクティスを作っていく必要がありそうです。
"中間者攻撃" タイプのフィッシングの脅威 : "本来のFIDO" が対応できてOTP方式で対応できない攻撃として、リアルタイムに正規のサービスの認証機能とやりとりしつつユーザーに認証を要求するフィッシング攻撃があります。正規のサイト "example.com" が表示するログイン画面をフィッシングサイトである "example.net" がプロキシのようにユーザーに表示して認証処理を要求した場合、ブラウザでFIDOの認証を行うとドメイン(origin)が変わるので認証は完結しません。しかし、"Decoupled Authentication" のスマートフォン上の認証フローでは "正しいFIDOの生体認証" が行われ、そのままフィッシングというかセッションのっとりが成功する可能性があります。ブラウザを経由しないフローではブラウザを用いた対策はできない。それは当然です。

このあたりの対策、ベストプラクティスが固まった時点でやっと "Decoupled Authentication" が使われ始めるのかもしれません。

まとめ

長くなりましたが、まとめると

LINEがスマートフォンを用いて別端末にログインする仕組みを発表したので触ってみた
"手元のスマートフォンでログイン" する "Decoupled Authentication" が熱くなってきてる
"Decoupled Authentication" と FIDO, OIDC CIBAとの関係を整理した
課題はあるが "Decoupled Authentication" が使われる時代はすぐそこまできている

というところです。今後もDecoupled Authenticationに注目していきましょう。

そういえばアドカレ埋まりました。参加表明をしていただいたみなさん、ありがとうございます。

qiita.com

ではまた。

2020-11-05

EMV® 3-D Secure × FIDO で目指す世界とは?

FIDO Payment 3DS Security

f:id:ritou:20201105022724p:plain

おはようございます。ritouです。最近寒いです。もうダメ。

なんの話か

今日はこのお話です。

EMVCo publishes new guidance for merchants and issuers on using @FIDOAlliance authentication with EMV® 3-D Secure for improved online payment experiences. Find out more: https://t.co/mR1cFthoq8 pic.twitter.com/iCpk1wktYV
— EMVCo (@emvco) 2020年10月29日

ICYMI [White Paper] @emvco explains how merchants and card issuers can use #FIDO #authentication to streamline #onlinepayments, reports @nfcw Get the details here: https://t.co/TOOdwO3xs0 pic.twitter.com/X55TTUux7x
— The FIDO Alliance (@FIDOAlliance) 2020年11月4日

EMVCoとFIDOアライアンスがタッグを組む的な話です。なんかさっぱりいいねが少ないですが、気になりますね。

読む前に期待してたこと

人間(あるいは猫)はリンク先を確認する前に内容をある程度決めつけちゃう生き物です。~~そりゃあTwitterも中身見てみろとか言ってくるわけです。~~

3DSってこういうやつじゃないですか。

(ref. https://pointofsale.com/emvco-launches-emv-3-d-secure-2-0-specification/)

(図では3DS Requestorとなってる)MerchantからDSを経由してIssuerに認証要求が送られる
(毎回もしくは必要に応じて)Issuerは認証を要求する

なので今回の件、なんとなくこう思っていました。

3DS 2.0からは「必要な時だけ認証を要求してEコマースなどの離脱を防ぐ」みたいな感じだし、きっとその認証にFIDOを使う話なのかなー...
そういえば3DSの認証を行うドメインがどうこういう話があったな...FIDO2(WebAuthn)だとドメインというかoriginのあたりも重要になるのでAuthenticatorの登録はこうするとか書かれてるのかなー...
手元のスマホに入ってる公式アプリ + UAF でいよいよ本格的な Decoupled AuthN 時代来るかなー...

f:id:ritou:20201105024925p:plain

で、読んでみました。

書いてあったこと

想像してたのとちょっと違いました。

The ‘Use of FIDO Data in 3DS Messages’ white paper focuses on the newly defined FIDO attestation data set. Using this defined data set, merchants can deliver a structured set of data elements and present the card issuer with a consistent set of values for the same user or device (along with other data they would receive as part of an EMV® 3DS transaction), reducing the need for repeated consumer authentication.

...

“Outlining exactly how the data can be used by card issuers to analyse merchant-initiated FIDO Authentication as part of their risk evaluations, can increase authorisation approval rates, streamline online checkout and reduce fraud,”

資料: https://www.emvco.com/wp-content/uploads/documents/EMVCo_3DS_FIDOData-WPv1.0_20200710.pdf

ということで、

FIDOで認証を行うのはMarchantであり、その結果(の一部)もしくはユーザーに紐づく情報を Issuer に送る
Issuer はそれを含むユーザー/デバイスのデータを使って認証を要求するかを判断

という感じです。

f:id:ritou:20201105024944p:plain

そっちかい！と思いつつも、3DSはMerchantが決済などをしたい環境、デバイス情報を送りまくってリスクを判別するっていう考えなのでその中にFIDOのデータを使うという考えはなるほどなーという感じもします。

毎回FIDOで認証するわけじゃなく、FIDOのデータも含められるようにするよと。とはいえ「3DSでの認証スキップの可能性が上がる」ためにMerchantがFIDOでの認証を入れてくれるかってとこが気になります。まぁ、そこ気にならないぐらいFIDOを普及させれば良いんですね。そうですか。

誰が実装するか？

これ実際どうやって実装されることになるかというと

Merchant自身が元々実装してたのでそれを決済機能に組み合わせて使う
Merchant自身がこのために導入
3D Secure Merchant Plug-In、SDKがやってくれる未来

の3パターンがありえるかもしれません。2,3は重複するかもしれない。

3DS 2.0でIssuerがリスクベース認証を行うためにたくさんの環境データを利用できるように、3のPluginがSDKを利用して情報を吸い上げる実装があります。 Web用のSDKnならばWebAuthnを呼び出し、結果を保存しておく仕組みやバックエンドから吸い上げる仕組みがあると普及のハードルは下がるかもしれません。

送られるデータ

Merchantから送られるFIDO関連データは次の通りです。

{
  "authTime": "2020-08-08T07:42:17Z",
  "rpId": "https://emvco.com",
  "FIDOAuthenticatorReferences": [
    {
      "publicKey": "BJDLvkKkuXRpn3bWh_hiJQb8lJNd9kTXEmQgEwoHezkNI_VPGd3vrjrWyZTfgxVDl9_Tp ixrVjmEAEmegmfL2WI",
      "aaguid": "0132d110-bf4e-4208-a403-ab4f5f12efe5",
      "uv": true,
      "up": true,
      "usedForThisTransaction": true
    }
  ]
}

WebAuthnとか触った人ならわかりますね。

authTime
rpId or appId
FIDOAuthenticatorReferences
- publicKey
- aaguid or Aaid
- usedForThisTransaction : Merchantの現在のセッションで使われたらtrueがセットされる
- Up : セキュリティキーやブラウザの所持を確認したか
- Uv : PINや生体認証をしたか

複数送っても構いません。あるだけ送れという感じです。

まぁ、公開鍵は送っても問題はないしとはいえ、セキュリティキーの緩い型番的な aaguid とかまで...って思ってしまいますが、元々3DS はえぐいデータを送れるような定義になってるのでこういうもんなんでしょう。以前、この3DSのリスクベース判定みたいなのをOIDC CIBAでもやれば...みたいな記事を書きましたので良かったらどうぞ。

ritou.hatenablog.com

Issuerはどうすんの？

先ほど紹介した情報を用いて認証を要求するかしないかを判断します。ここから先はIssuerの設計/実装に依存する話かと思うので書かれていなそう(別の仕様にあるかも)ですが、この辺りのベストプラクティスもあると良さそうです。

Issuer側でFIDO使わないの？

このあたりは今回の発表とは別で検討されるかもしれません。 FIDOを使ってはいけないということではないので、今後は使うところが出てくることを祈ります。上にも少し書きましたが、元々3DSの認証で使われるドメインがIssuerのドメインじゃなかったりするパターンもあるので、そのあたりはもう少し整理されないと「微妙に使いにくい組み合わせ」と言われかねません。

まとめ

EMV® 3-D Secure × FIDO ということで想像が膨らんだ
書いてある内容は予想と違ってMerchantがFIDOで認証した結果を送るものだった
これはこれで興味深いがMerchantの採用モチベーションは上がるだろうか...

うーん、まぁ、ちゃんと実装してくれるIssuer/Marchantが出てくると良いですね。

以上です。

そういえば今年もアドカレやりまっす。

作りました。Digital Identity技術勉強会 #iddance Advent Calendar 2020 https://t.co/ihQrvTifSc
— 👹秋田の猫🐱 (@ritou) 2020年11月3日

何人か参加表明をいただいております。満員になったら私の6枠を減らしてもいいので是非ご参加ください。

ではまた。

2020-10-22

OIDC CIBAで作る「スマートフォンでログイン」機能

CIBA OIDC Authentication U2F Passwordless

こんばんは、ritouです。

今日は OpenID Connect Client Initiated Backchannel Authentication Flow 通称CIBA のユースケースについて書きます。

CIBA は決済や送金のためのもの？

自分の記事でも、CIBAのユースケースとしてコンビニ決済への導入例を挙げてみたりしました。そして、CIBAにやたらと詳しい某Authlete社の記事を見ても、送金とか決済などで使えそうな話がプンプンします。

www.authlete.com

お金周りはUX改善のメリットとして伝え安いですし、クレカ決済のDecoupled AuthNの実例もあります。 CIBAもFAPIとの絡みがあるのでこの辺りを例示しがちではありますが、今回はそんな流れに逆張りとばかりにシンプルなユースケースに注目します。

「スマートフォンでログイン」の要件とCIBAの機能

例えば Google アカウントにログインする際、Androidデバイスなどを用いた次のような認証方式が利用可能です。

パスワードの代わりにスマートフォンで使用する <- パスワードレス!?
2 段階認証プロセスを有効にした場合に、パスワードに加えて使用する <- 2段階認証!?

support.google.com

Googleは次のようなメリットを挙げています。

f:id:ritou:20201020034338p:plain

SMSで受信した認証コードを盗まれるなどのリスクを回避
リッチなUI
拒否機能あり

SMSやOTPを使うよりは安心感が出そうですが、なかなか実装の敷居が高そうな機能です。言い換えると、これを簡単に実装できそうだとしたら面白くないですか？

このような機能を実現するための要件としては

ユーザーと端末が紐づいている : ユーザーとADの関係
端末にプッシュなどでの通知ができる : CIBA の AuthN Request を受けた OP が ADにプッシュ通知を送って...
必要ならば通知先の端末でユーザー認証 : CIBAではブラックボックスになっているがこの辺はよしなにやるべき内容
環境などリッチな情報を表示して許可を求める : AuthN Requestに情報を載せてやれば良い
ユーザーが拒否したら認証フローを終わらせられる : ADでユーザーが拒否したらエラーが返る

ということで、今回はこの「スマートフォンでログイン」をCIBAを使って実装するとどうなるか？っていう話をします。

GOAL

パスワードレス

Google の「スマートフォンでログイン」のUXを見てみましょう。まずはメールアドレスなどを入れてユーザーを特定します。

f:id:ritou:20201021215500p:plain

ここで設定が済んでいると、スマートフォンでログインのフローに入ります。スマートフォン見てみろやと。許可しろやと。そして下に書いてるのと同じ数字をタップしろやと。

f:id:ritou:20201021220705p:plain

ここで、手元のスマートフォンに通知が来ます。 2FAではなくこれだけでログインさせるので設定時に「この機能使う時、画面ロックかかるよ」って言われています。

スマートフォンで表示される画面はこんなんです。リッチな...とか言ってましたがあんまり情報ないですね。まぁいいか。

f:id:ritou:20201021220719p:plain

「はい」を押すと、さっき言ってた同じ数字をタップしろやと言ってきます。

f:id:ritou:20201021220731p:plain

これでログインできます。

2段階認証

違いとしては

ユーザー特定後、パスワード認証
パスワードがあっていたら「スマートフォンを確認しろ」画面(上述したような数字のくだりはなし)

というあたりです。

CIBAを用いた実装案

ここでは一旦、「利用するスマートフォンの設定が済んでいる」前提とします。

上で紹介したGoogleの例と揃えると、CIBAの仕様におけるOP/RPという役割がどちらも同一サービス(Google)とする方がイメージしやすいかもしれません。

RP : Webアプリやモバイルアプリ
OP : 認証基盤的なやーつ

最初に、RPはHTMLフォームなどでユーザー特定に必要な値を受け取ります。ここではメールアドレスとしましょう。

次に、RPからOPにバックチャンネルで AuthN Request を送ります。 (Client認証部分は省略しています。)

   POST /bc-authorize HTTP/1.1
   Host: server.example.com
   Content-Type: application/x-www-form-urlencoded

   scope=openid&
   binding_message=93&
   login_hint=user@example.com

パラメータとしては

login_hint : 対象ユーザーのメアド
scope : ログインできたらいいので openid のみ
binding_message : 上述のGoogleの例に揃え 93 を指定

というあたりがあれば十分そうです。レスポンスはこうなります。パスワードレス、2FAのコンテキストを指定したい場合は acr_values あたりを使っても良いかもしれません。

    HTTP/1.1 200 OK
    Content-Type: application/json
    Cache-Control: no-store

    {
      "auth_req_id": "1c266114-a1be-4252-8ad1-04986c5b9ac1",
      "expires_in": 120,
      "interval": 2
    }

このレスポンスを受けたら、RPはユーザーに「スマートフォンを確認しろ」「binding_messageで指定した値を選択しろ」という画面が出せます。一方、OPはAuthN Requestを受けたらユーザーのAD(スマートフォンのアプリなど)に通知を送ります。

通知を受けたADでは

(パスワードレスをうたうなら)画面ロックなどの再認証要求
対象ユーザーのプロフィール画像、メアドの取得
ログインしますか？とユーザーに聞く
「はい」の場合に、binding_message に指定した値とそれ以外の値を払い出し、選択させる

binding_message のあたりは独自でルールを決めつつって感じですが、1 ~ 99 までの数とかに制限しておくと Google のような画面が作れそうです。 OKならRPはIDTokenを取得でき、認証成功したことを検証できます。

ということで、ほぼCIBAの仕様範囲内で実装できそうです。 まぁ、ここまで理解してできる開発者ならもうちょっとシンプルに設計/実装できそうな気もしなくはないですが。

CIBAを利用するにあたり、考えるべき点

RPがWebアプリの例を示しましたが、モバイルアプリでも同様に実装できそうです。ただし、CIBAはConfidential Clientを対象としているのでリクエストを送るWebサーバーを間に置いておく必要があるかもしれません。

あとは前提のあたりで書いた「RP/OP」が別サービスの場合ですが、

最初にRP(example.com) 内でユーザー特定し、そこから先(AD上の表示など)はOP(example.net)のコンテキストで行われるあたりのユーザーへの見せ方
RP->OPのAuthN Requestの login_hint に指定する値

あたりをよく検討してユーザーが気持ち悪く思わないようなUXに仕上げる必要があるでしょう。

登録

上にも書きましたが、CIBAの仕様では、ADとの紐付けは仕様の対象外です。この辺りはよしなに...とすると悩んじゃいそうなので、この前書いたDevice AuthZ GrantっぽいUXを使って登録フローを考えても良いと思います。

ritou.hatenablog.com

リッチなUI、環境に関する情報

Googleでは2FAの時の画面では

デバイス(OS情報?)
場所(ネットワーク情報?)
時刻

などを表示していました。ユーザーへの表示以外にもOP側でリスク判定などに使える値だったりするので、目的外利用とか言われないようにちゃんと同意を得た上で環境に関する情報をやりとりしても良いでしょう。

まとめ

CIBAを使って「スマートフォンでログイン」的なパスワードレス、2FAの仕組みが作れそう
RP/OPが同一サービスだったらシンプルに作れそう
RP/OPが別で「2FA専用SaaS」みたいなのも面白そう

この辺りはプッシュ通知を受けられるPWAなWebアプリでも作れることはわかってるので、どこかでデモできればいいなと思っております。これからもAuthentication Device (AD)を使うユースケースを探究できたらと思います。

ではまた！

f:id:ritou:20201021234131p:plain

2020-10-19

OIDC CIBA の拡張として OAuth 2.0 Device AuthZ Grant を使う仕様を考えてみた

CIBA DeviceFlow OIDC OAuth Authentication

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

なんか急に寒くなりましたね。私は先週末、風邪をひきました。

何の話？

OpenID Connect の CIBA と OAuth 2.0 Device AuthZ Grant は手元の端末を用いてユーザーがID連携やリソースアクセスを許可することから似ている面があるものの、プロトコルとしては結構な違いがあります。

ritou.hatenablog.com

tools.ietf.org

あまり深く考えずにこれらの標準化仕様を弄ってどうこうするのはお勧めできないわけですが、今回は特定の条件下においてこの2つを組み合わせられるのでは？というのを考えてみました。

それぞれの特徴

リクエストやらエンドポイントやらのプロトコルの詳細は一旦おいておいて、ざっくり

CIBA
- RPがOP上のユーザーに紐づく情報を知っている必要がある
- 事前にユーザーと Authentication Device (AD) の紐付けが存在し、AD上でID連携を許可する。紐付け方については仕様範囲外
Device AuthZ Grant
- Clientは事前にユーザーを知らなくても良い
- ClientがURL+User Code や QRコードを表示して、ユーザーが自らが利用する端末のブラウザを利用してリソースアクセスを許可する。

のように整理できます。

こう書くと結構な違いがありますが、一方で綺麗に仕様が分かれているようにも感じられるのではないでしょうか。

組み合わせの可能性

FAPIとかのガチなユースケースでは変なこと考えない方が良いと思いますが、C向けの比較的ライトウェイトなサービスとかでは既存の仕様を弄り回すのも頭の体操ぐらいにはなりそうです。

自分でPWAを用いたCIBAのデモを作ってみたりして気付いたんですが、CIBAで前提となっているもののその部分自体は未定義である「ADとユーザーの紐付け」や「RPとの最初のID連携」の部分を簡単にやれるといいなーという思いが出てきました。

そんな中、この2つの仕様が交わるユースケースを考えてみたところ、例えば PWA なWebアプリやモバイルアプリなどで

OIDC CIBA のように AD が Push を受けられる
OAuth 2.0 Device AuthZ Grant のように URL や QRコードで起動できる

という2つの要件を満たせるならば 「OIDC CIBA で RP とユーザーの紐付けがない状態の時だけ Device AuthZ Grant っぽく」みたいなのができて上記の課題を解決できるのでは？と思ってきました。そこで、OIDC CIBA の拡張として OAuth 2.0 Device AuthZ Grant を使う仕様 を考えてみたわけです。

OIDC CIBA Dynamic AD Enrollment Extension(仮)

ここからが本番です。いきなりまとめると

CIBA の Backchannel Authentication Endpoint への Authentication Request で指定した *hint が空だったり OP 側で紐付けがない/切れた場合に OAuth 2.0 Device AuthZ Grant の Device Authorization Response を返す
それにより、動的なAD紐付けが可能になる

みたいな感じです。わかりますか？わかりませんよね。もうちょっと詳しく説明してみます。

動的なAD紐付け(拡張)

OP上でユーザーとADの紐付けが行われていないもしくはリセットされたような状態からの動的な紐付けを行うケースを想定します。あとはADが複数存在する場合にRPに対して利用するADを選択するようなケースとかでも使えそうです。

f:id:ritou:20201019005740j:plain

図ではCIBAのPoll modeを想定していますが他のmodeでもあまり変わりません。

1. Authentication Request

RPはOPに対して Authentication Request を送ります。

  POST /bc-authorize HTTP/1.1
   Host: server.example.com
   Content-Type: application/x-www-form-urlencoded

   scope=openid%20email%20example-scope&
   client_notification_token=8d67dc78-7faa-4d41-aabd-67707b374255&
   binding_message=W4SCT&
   login_hint_token=eyJraWQiOiJsdGFjZXNidyIsImFsZyI6IkVTMjU2In0.eyJ
   zdWJfaWQiOnsic3ViamVjdF90eXBlIjoicGhvbmUiLCJwaG9uZSI6IisxMzMwMjg
   xODAwNCJ9fQ.Kk8jcUbHjJAQkRSHyDuFQr3NMEOSJEZc85VfER74tX6J9CuUllr8
   9WKUHUR7MA0-mWlptMRRhdgW1ZDt7g1uwQ&
   client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3A
   client-assertion-type%3Ajwt-bearer&
   client_assertion=eyJraWQiOiJsdGFjZXNidyIsImFsZyI6IkVTMjU2In0.eyJ
   pc3MiOiJzNkJoZFJrcXQzIiwic3ViIjoiczZCaGRSa3F0MyIsImF1ZCI6Imh0dHB
   zOi8vc2VydmVyLmV4YW1wbGUuY29tIiwianRpIjoiYmRjLVhzX3NmLTNZTW80RlN
   6SUoyUSIsImlhdCI6MTUzNzgxOTQ4NiwiZXhwIjoxNTM3ODE5Nzc3fQ.Ybr8mg_3
   E2OptOSsA8rnelYO_y1L-yFaF_j1iemM3ntB61_GN3APe5cl_-5a6cvGlP154XAK
   7fL-GaZSdnd9kg

OIDC CIBAで定義されていいるそのまま載せましたが、今回の拡張を利用するための追加のパラメータが必要になるかもしれません。

CIBAでは*_hintパラメータで指定されたユーザーを特定し、存在しない場合やユーザーが管理しているADと通信できないなどの場合はエラーとして扱いますが、今回の案ではエラーではなく「OAuth 2.0 Device AuthZ Grant」風のレスポンスを返すものとします。

      HTTP/1.1 200 OK
      Content-Type: application/json
      Cache-Control: no-store

      {
        # CIBAのauth_req_id は OAuth 2.0 Device AuthZ Grant の device code 相当
        "auth_req_id": "1c266114-a1be-4252-8ad1-04986c5b9ac1",

        # ここから下が OAuth 2.0 Device AuthZ Grant のレスポンス
        "user_code": "WDJB-MJHT",
        "verification_uri": "https://example.com/device",
        "verification_uri_complete":
            "https://example.com/device?user_code=WDJB-MJHT",

        # 有効期限とインターバルの間隔
        "expires_in": 1800,
        "interval": 5
      }

2. User Interaction

RPは受け取ったverification_uri + user_code や verification_uri_complete をユーザーに提示し、ユーザーはそこにアクセスします。 CIBAのユースケースとしてPOS端末での利用がありましたが、例えばポイントカードを持っていたらスーパーのATMやサービスカウンターにある端末などで最初にこの辺りの設定をする、とかでも良いでしょう。

3. AD Enrollment & Consent

ここで

ADとしての登録 (AD Enrollment)
RPにユーザー情報を提供することへの同意 (Consent)

などが行われます。

4. Polling Request / Response(NG)

3 が完了するまでは、RPからのPolling Requestに対してOPはエラーを返します。

5. Polling Request / Response(OK)

3 が完了すると、RPからのPolling Requestに対してOPは成功レスポンスを返します。

通常のCIBAフロー

ユーザーとADが紐付けられていて、RPからのAuthentication Requestでユーザーを特定できた場合は通常のCIBAのフローになります。

f:id:ritou:20201019005237j:plain

GNAP, 3D Secure 2.0

以前、XYZとして紹介したドラフト仕様を覚えているでしょうか？

ritou.hatenablog.com

現在はGrant Negotiation and Authorization Protocol(GNAP)として仕様策定が進められています。

tools.ietf.org

これ、最初の頃から

バックチャンネルでリソースアクセスを要求
必要であればユーザーインタラクションが発生

という流れになっていました。

OAuth 2.0に求められるユースケース毎の要件を整理し、OAuth 1.0の時のようなバックチャンネルのリクエスト中心のプロトコルとして書き直した感じです。

なので今回紹介したやつとほとんど一緒です。

さらに、XYZの紹介記事でちょっと触れた様に 3D Secure 2.0 のフローにも似ています。

3dsecure2.com

この辺りは細かいパラメータなどは異なるにせよ、大まかな仕組みとしては似ているところに落ち着いていきそうな気がします。

まとめ

OIDC CIBA と OAuth 2.0 Device AuthZ Grant の組み合わせを考えてみた
OIDC CIBA の仕様外である「ADの登録」のところに OAuth 2.0 Device AuthZ Grant の「動的なリソースアクセス許可」を適用することで「動的なAD登録」みたいなのが実現できそう
XYZ(GNAP)とかと似てる

せっかく仕組み考えたので、次回はこれを使った「OIDC CIBA as a MFA」みたいな話を書こうかと思っています。ではまた！

f:id:ritou:20201017234812p:plain

2020-10-12

2020/11/19 に「idcon vol.28 DID特集その2」やります

DID DigitalIdentity 勉強会 OIDC

こんにちは、ritouです。

あの #idcon がオンラインで復活！？しかもテーマはDecentralized Identity(DID)！？と言うことで誰かの意識が高まっているのを観測したのでやります。

idcon.connpass.com

今のところの発表案です。

「MSのDID/VC概要」by phr_eidentity : MSのDID/VCを触ってみたので解説します。
「Credential Handler API（仮）」by kg0r0
「DIDCommとかSIOP」by ken5
「Email, Messaging, and SSI/DID: Round2」by s01 : Email, Messaging, and SSI/DID の日本語再放送 + DIDCommで本当にいけるのかという話

順番はテキトーに決めましたが、最初に概要から入り、Credential Handler APIとかDIDCommとかSIOPとか、個別のトピックについて解説されると一気に理解が進むのではないかと期待しています。

そして、大体は こんな感じだよ -> へー、なるほどー終わりーとならない(!)のが idcon でもあります。

MSはわかった。他に試せるところって？
Credential Handler APIって必要？SIOP拡張したったらこんなのいらなくね？
DIDCommってもっとシンプルにならんの？

と言ったあたりはいつもの idcon だと発表の後で盛り上がるところなので、オンラインでも白熱した議論が行われると良いですね。

配信どうしようかまだ決めていませんが、なるようになるでしょう。11月になったら考えます。

と言うことで、参加申込み募集中で〜す。ではまた！

(そろそろ iddance もやらないとなぁ...)

f:id:ritou:20201012185719p:plain

2020-09-22

Self-Issued OpenID Connect Provider DID Profile v0.1 とは

SIOP OIDC DID SSI

f:id:ritou:20200922040730p:plain

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

今日はこれを読んでみます。

Self-Issued OpenID Connect Provider DID Profile v0.1

何のための仕様か

This specification defines the "SIOP DID Profile" (SIOP DID) that is a DID AuthN flavor to use OpenID Connect (OIDC) together with the strong decentralization, privacy and security guarantees of Decentralized Identifiers (DID) for everyone who wants to have a generic way to integrate Identity Wallets into their web applications.

WebアプリケーションにIdentity Walletを統合するために
DIDとOpenID Connectの組み合わせるための
SIOP DID Profileじゃ！

と言うことです。

SIOPについてはもう大丈夫でしょうか？七年前の記事で良ければどうぞ。

ritou.hatenablog.com

Qiitaにもいくつか記事があります。

qiita.com

OpenID Providerとして特定のWebアプリケーション(Googleとか)ではなく、モバイル端末内で動作するアプリケーションなどを利用する
openid:// と言うカスタムURIスキームを用いた認可リクエストにより呼び出され、鍵ペアを生成/管理してIDToken を返す
ユーザーの同意のもとで端末単位で保存している情報のやりとりや、使い方次第では端末の識別やリクエストが同端末から送られたことの検証などにも使おうと思えば使える

と言うものであり、仕様としてはモバイルアプリ、ブラウザのプラグイン、デバイスの機能など特定のURI呼び出しを検知して起動できる仕組みで使えるように汎用的に作られています。

この仕様では、特定のサービスではなく端末自体をOPにすると言うSIOPをDID/SSIのIdentity Walletとして使うために必要な差分なりが定義されています。

Protocol Flow

RPはWebアプリ/ブラウザベース(SPAなど)のアプリであり、モバイルもしくはデスクトップブラウザからIdentityWalletアプリを立ち上げて使う想定です。公式の図を見てみましょう。

流れをざっくりまとめると、

RPは "Sign-in with SSI" ボタンみたいなのを用意し、ユーザーが押すと SIOP Request を生成
openid://?<SIOP Request> として何やかんやで Identity Walletアプリが起動する
Identity Walletアプリは OIDC/DID AuthN に従って SIOP Request を検証する
必要なら認証をして、その後に SIOP Response を作成する
response_mode の指定にしたがってRPにSIOP Responseが渡される
RPはOIDC/DID AuthN に従って SIOP Response を検証する

となります。

基本的にこのSIOPの流れに、DID用の処理が追加されるイメージです。

SIOP Request : RPは自身のDIDを含み、DIDドキュメントから検証可能な秘密鍵で署名を生成
SIOP Response : SIOPは自身のDIDを含み、DIDドキュメントから検証可能な秘密鍵で署名を生成

それでは見ていきましょう。

Generate SIOP Request

SIOP Request は次のように定義されています。

互換性のため、response_type, scope, client_id を文字列で指定する
それ以外のパラメータは request もしくは request_uri として指定する。RPのDIDもこっちで指定。

例を引用します。

openid://?response_type=id_token
    &client_id=https%3A%2F%2Frp.example.com%2Fcb
    &scope=openid%20did_authn
    &request=<JWT>

openid://?response_type=id_token
    &client_id=https%3A%2F%2Frp.example.com%2Fcb
    &scope=openid%20did_authn
    &request_uri=https%3A%2F%2Frp.example.com%2F90ce0b8a-a910-4dd0

いわゆるリクエストオブジェクトを指定、なんてのはFAPIなどのProfileでも使われているので驚きはないでしょう。

SIOPのフローでは、registration パラメータによってRPのメタデータを登録できます。

アルゴリズムは RS256 に加えて ES256K、 EdDSAをサポートしなければならない
Request ObjectはDIDドキュメントに記載されている検証方法で直接/間接的に検証可能であり、RPのJWKSにより直接検証可能である必要がある
JWKSは jwks_uri もしくは jwks パラメータで指定され、jwks の場合は kid が一致する必要がある。jwks_uriの場合はHTTP(S) DID Resolution Bindingが必要とか...
RPはSIOP Responseを暗号化して受信することもできる

リクエストオブジェクトについても細かく書いてありますが、眠いので例示に留めます。

#header
{
    "alg": "ES256K",
    "typ": "JWT",
    "kid": "did:example:0xab#veri-key1"
}

# payload
{
    "iss": "did:example:0xab", # RP's DIID
    "response_type": "id_token",
    "client_id": "https://my.rp.com/cb",
    "scope": "openid did_authn", # did_authn を指定
    "state": "af0ifjsldkj",
    "nonce": "n-0S6_WzA2Mj",
    "response_mode" : "form_post",
    "registration" : {
        "jwks_uri" : "https://uniresolver.io/1.0/identifiers/did:example:0xab;transform-keys=jwks",
        "id_token_signed_response_alg" : "ES256K"
    }
}

SIOP Request Validation

SIOPは scope に did_authn が指定されていたら、OIDCで定義されている検証に加え次のような検証を行います。

iss クレームで指定されたRPのDIDからDIDドキュメントを取得
jwks_uriが存在する場合、iss とDIDが一致することを検証
RPのDIDドキュメントから、kid と一致する検証方法を取得
SIOP Requestの検証

Generate SIOP Response

SIOPは以下のような SIOP Response を作成してRPに戻します。

sub_jwk は kid を含む
- kid はSIOPのDIDドキュメントの検証方法を参照する DID URL
SIOPのDIDを含む : did クレーム

# Header
{
    "alg": "ES256K",
    "typ": "JWT",
    "kid": "did:example:0xab#key-1"
}

# Payload
{
    "iss": "https://self-issued.me",
    "nonce": "n-0S6_WzA2Mj",
    "exp": 1311281970,
    "iat": 1311280970,
    "sub_jwk" : {
        "crv":"secp256k1",
        "kid":"did:example:0xcd#verikey-1",
        "kty":"EC",
        "x":"7KEKZa5xJPh7WVqHJyUpb2MgEe3nA8Rk7eUlXsmBl-M",
        "y":"3zIgl_ml4RhapyEm5J7lvU-4f5jiBvZr4KgxUjEhl9o"
    },
    "sub": "9-aYUQ7mgL2SWQ_LNTeVN2rtw7xFP-3Y2EO9WV22cF0",
    "did": "did:example:0xcd" # SIOPのDID
}

(ちょっと追記)通常のSIOPは鍵を生成して端末なりに保存しておくだけのイメージですが、ここではDIDを含みDIDドキュメントから検証できるようにする必要があるわけなのでこれまでのSIOPの感覚で言うと鍵の登録処理も発生しそうです。もう少し細かく追記してもらうのが良いのかなと思ったりします。

SIOP Response Validation

OIDCのSIOP Responseの検証としては

id_token を取得
id_token が sub_jwk の鍵で署名されたことを検証

さらに DID AuthNとして

id_token の SIOP DID(did) から DIDドキュメントを取得
id_tokenのDIDドキュメントから sub_jwk の kid と一致する検証方法を取得
その検証方法で id_token を検証

SIOP Discovery

省略します。

UX Considerations

カスタムURLスキームの扱いについて。モバイルブラウザの場合はアプリ立ち上げるけどAndroid/iOSそれぞれで今までもいろいろ言われてきたよねと。デスクトップブラウザの場合、もしかしたらブラウザ拡張/プラグインでサポートされるかもしれないけどうまくいかなそうならIdentity Walletのアプリを開かせてQR読み込ませるとかが必要かも。

この辺りが改善されるにはもう少し時間がかかるかもしれませんね。

Security Considerations

まずはSIOP ResponseのIDToken漏れるかも問題

Interception of the Redirect URI : SIOP Responseを取られたらIDToken持っていかれるよ -> RP頑張れ(オープンリダイレクト作るな)
Identity Token Leak in Browser History : ブラウザの履歴からSIOP ResponseのIDToken漏れるよ -> IDTokenの有効期限短くしたりキャッシュされないようにしたりしよう。完全な対策は難しいかも。
Identity Token Leak to Third Party Scripts : SIOP Responseをを受ける時に3rd PartyのJSとかでIDToken持っていかれるよ -> RP頑張れ(信頼できるやつだけ使え)

対策として response_mode=form_post 使えるならう。無理な場合もあるけど。とあります。

次に Session Fixation in Cross-Device Flow として、異なるデバイス間の転送を含む場合の脅威が記載されています。 RPがQRコードからIdentity Walletを呼び出す仕様の場合、攻撃者は自らのセッションに紐付いたQRを読ませることで第3者の認証を攻撃者のセッションでできるかも。対策としては同一セッションであることの確認、もしくは異なるデバイスでも同一ユーザーであることを別の認証方式などで確認することが必要。

Github

何かあったらここでやってるよと。

github.com

(追記)SIOP側の公開鍵登録についてもう少し説明必要では？みたいなことを書いてみました。

github.com

まとめ

SIOPの流れにDIDの検証処理を追加するProfile
RPが作るリクエストオブジェクトの部分がモリモリしてるがSIOPのフローは変わらない
カスタムURIスキームやQRコード使う部分はもうちょい改善されないとUXキツそう

と言うあたりでしょうか。引き続きウォッチしていきましょう。ではまた！

2020-09-03

フィッシング対策視点から考えるメールやSMS通知のあり方

Authentication Phishing Notification Email SMS

こんばんは、ritouです。

令和の時代においても、フィッシング攻撃はメール、SMS共に存在します。だいぶ普及してきたみんな大好きワンタイムパスワードでもフィッシングに対しては脆弱です(FIDOにしましょう)。フィッシング攻撃への現状の対策はどうかというと、メール自体の検証、メールにあるURLの表示と実際のリンクの差異、URLが正規のものかを確認することは素人になればなるほど困難です。 SMSならばURLはテキストそのものだから安心かもしれませんが、そもそも正規のメッセージに偽物が混ざってきたらわかりません。

ということで、今回は「メールやSMSにできるだけURLや電話番号などを記載するのを避けよう。」という話です。

主張

例えばこの記事

keepmealive.jp

それならば対策は二つだけ 1. SMSに書かれているURLは原則としてクリックしない 2. どうしてもクリックする必要があるときは本物のURLか確認するということになります。

ここではdocomoの正規のURL(ドメイン)のリストがずらっと並んでいますが、このような検証を幅広いサービスに適用していくことは困難です。なので、「メールやSMSにできるだけURLや電話番号などを記載するのはやめよう。」という意見ですね。

某、徳●さんのTweetで見かけたんですが、

pc.watch.impress.co.jp

同社では、「正規の当選メールには、サイトのURLの記載やリンクはなく、申し込み時に登録する『マスク抽選販売サイト』にある『当選者専用サイト』から登録する設計になっている。偽の当選メールに記載されているサイトのURLに行かないようにしてほしい」としている。

まさにこれですね。

UX低下を防ぐ仕組み

この話をすると、URLや電話番号を載せなかったらUXが悪くなるのでは？と言われることがあります。フィッシングサイトや業者まで一発で引っ張っていけるということで、それだけURLや電話番号を利用することは効率的なUXであるとも言えるでしょう。正規の通知しか送られてこない前提になっている、例えばモバイルアプリの通知のような場合はそこからアプリを立ち上げて...というUXを変える必要はないでしょうけれども、フィッシング攻撃の可能性がある限りはその部分を取り除きつつ通知の詳細確認やその後の必要な処理への誘導について、代替手段を用意する必要があります。通知に含まれたURLや電話番号に直接アクセスする代わりに、Webアプリやモバイルアプリに通知を確認できる場所を用意しておき、ユーザー自身でそこにアクセスしにいく方法が良いのではないかと。

今まで
- 通知の概要(メール/SMS) -> URLクリック -> 詳細確認や継続処理
これから
- 通知の概要(メール/SMS) -> (自分でブックマークなどからWebアプリに移動) -> 詳細確認や継続処理
- 通知の概要(メール/SMS) -> (手元の端末でモバイルアプリを起動) -> 詳細確認や継続処理

「これから」の方に書いたUXが定着していくと、フィッシング攻撃が来ても「このフロー変じゃない？」と気付けるような仕組みの上での「啓蒙活動」もやりやすくなり、世界の平和に向けて一歩前進できるのではないでしょうか。サービスの種類にもよりますが、個人的にはこの方が通知を受けたデバイスと実際にサービスに到達しにいくデバイスが異なるパターンでも利用できそうですし、UXは向上するのではないかと思ったりします。。

SMSやメールにURLや電話番号を含まない方がセキュアなんだけどサービス側はついいれたくなるし、フィッシング対策でドメインを確認しろ、ユーザーが気を付けろという説明も未だにあるのでこれは我慢強く広めていかないといけない
— 👹秋田の猫🐱 (@ritou) 2020年9月2日

まぁ、実際にプロダクトでやろうと思ってもなかなか受け入れられないかもしれませんが、さいきょうのアイディーを求めることは悪いことではないでしょう。ではまた！

f:id:ritou:20200903010702p:plain

2020-08-25

現在仕様策定中の OpenID Connect RP-Initiated Logout 1.0 とは

OIDC Session Extension Spec

こんばんは ritouです。

むかーしむかし、あるところにOIDCのセッション管理に関する3つの仕様がありました。

(2015年の記事)

ritou.hatenablog.com

(Session Managementについてのさらに古い 2013年の記事)

ritou.hatenablog.com

いわゆるソーシャルログインと呼ばれる使い方ではRP/OP間のセッションの整合性をあまり意識しない感じになっていますが、昔から使われている "SSO" 的な使われ方においてはそのあたりが意識されるかもしれません。これらの仕様ではRP/OP間でセッションに変更がないか、ログアウトさせるいくつかの方法が定義されています。

これらは最近どうしてるのかな？というところで現状を見てみると、4つの仕様として策定が進められています。

OpenID Connect Session Management 1.0 - draft XX
- RPからOPへのログアウト要求部分が分離されました OpenID Connect RP-Initiated Logout 1.0 - draft XX
HTTP-Based Logout -> OpenID Connect Front-Channel Logout 1.0 - draft XX
Back-Channel Logout -> OpenID Connect Back-Channel Logout 1.0 - draft XX

[Openid-specs-ab] RP-Initiated Logout is now its own specification

また、既にOpenID Certificationにはテストも用意されており、パスしたOPも書かれています。

openid.net

f:id:ritou:20200819024520p:plain

というところで、今回はこのRP-Initiated Logoutについて概要(not 翻訳)を紹介します。

openid.net

This specification complements the OpenID Connect Core 1.0 specification by enabling the Relying Party to request that an End-User be logged out by the OpenID Provider.

これはOPによるエンドユーザーのログアウトをRPから要求できるようにするための拡張仕様です。

新しい用語

これぐらいです。

Logout Endpoint : RPがログアウトのリクエストを送るターゲットとなるOPのエンドポイント

RPはこの値を後述する metadata から取得したりドキュメントとかで把握する必要があります。

RPからOPへのログアウト要求

RPがOPにログアウトを要求するパターンとして、2つあります。

RP -> OP と遷移して終わるパターン
RP -> OP -> RP に戻ってくるパターン

前者の場合、必要なパラメータは

id_token_hint : OPからRPに過去に発行されたID Tokenの値をヒントとして指定。RECOMMENDED
ui_locales : OP上での優先言語、スクリプトの指定。OPTIONAL

となります。AuthZ(AuthN) Requestのように client_id パラメータを用いて明示的に Client を指定したりはありません。 id_token_hint パラメータがあった場合、事前に ID Token にセッション識別子である sid を入れておくことで現在のセッションと一致するかどうかの判定ができますが、ない場合や検証不可な場合はOPとしてはユーザーがどこから来たのかさえわからない(信用できない)状態になります。

セッションとIDTokenの関連というと今までも何度か記事を書いてきましたが、今回のようなセッション関連の仕様を読むときは、IDTokenをセッション識別という目的で一定期間保持することを想定しなければなりません。有効期限はサーバー時間のずれに影響でないぐらいになるべく短くしIDTokenを取得したタイミングで "ID連携" を行う、という本来のOIDCの考え方との違いについてよく頭の体操をしておく必要があるでしょう。(個人的には id_token_hintという使い方が大っ嫌いなのですが精一杯大人な書き方をしています。)

また、仕様中に突然出てくる sid ですが、これは OpenID Connect Front-Channel Logout で定義されています。仕様の最初の方で他のセッション関連の拡張仕様との関連について言及はありますが、sid がどこで定義されたものかが言及されていないと、初めて見た開発者は混乱するかもしれません。

Draft: OpenID Connect Front-Channel Logout 1.0 - draft 04

sid Identifier for the Session.

OPはログアウトURLでユーザーに対して「ログアウトしますか？」と尋ねるべき(SHOULD)とあります。これを行うとユーザーの意図せぬ挙動を防ぐのと同時に、後述するトラッキング判定に対しても効果があるかもしれません。

ここまでの流れを図にしました。

f:id:ritou:20200825010654p:plain

複数のRPに接続済みのOPはログアウト後に、SessionManagementでのセッション判定で "状態変更あり" を示したり、Front-Channel/back-Channel Logoutの仕様でRPにログアウト通知を送ります。

さらに、RP->OP->RPと戻る場合はパラメータが変わります。

id_token_hint : OPからRPに過去に発行されたID Tokenの値をヒントとして指定。REQUIRED
post_logout_redirect_uri : OPのログアウト後にRPに戻したい時に指定する戻り先URL。このURLが指定されるときは id_token_hint の値が必須となる。検証の際は完全一致。
state : 戻り先がある時のCSRF対策のための...(略。必須でいいだろ(OPTIONAL)！
ui_locales : OP上での優先言語、スクリプトの指定。OPTIONAL

f:id:ritou:20200825010923p:plain

この場合は id_token_hint も必須になりますが、ここまでやるならAuthZ Requestのように client_id などを利用する方が良いのではないかと個人的には思います。

この仕様の概要としてはこんな感じです。

Metadata

OP/RPのURLの扱いが書かれています。

OpenID Provider Metadata

OpenID Provider Metadata では RP が Logout Endpoint を Discovery できるように、end_session_endpointという値を定義します。

Client Registration Metadata

OP が RP-Initiated LogoutとDynamic Registrationをサポートする場合、post_logout_redirect_uris という値を事前に登録します。

ITP, SameSite Cookieとセッション関連仕様への影響

ちょうど先日、OpenID TechNight vol.17 ~ with コロナ編でiframeを使うユースケースへの影響について説明されていました。

https://www.youtube.com/watch?v=0856pHMoTDs

その中で、iframeを使っているために影響が考えられる仕様として2つが紹介されていました。

Session Management
Front-Channel Logout

それぞれの仕様にもこの影響については言及があります。

Session Management - 5.1. User Agents Blocking Access to Third-Party Content「RPコンテキストで呼び出したOPのフレームがCookieにアクセスできず、ログイン状態が変更されたという応答を返し、再認証されまくるかも」
Front-Channel Logout - 4.1. User Agents Blocking Access to Third-Party Content「frontframe_logout_uriがOPによってレンダリングされた時にRPのログイン状態にアクセスできなくてログアウトされないかも」

今回のRP Initiated Logoutでは、OPはLogout EndpointへのアクセスでGET/POSTをサポートしなければならない(MUST)とあります。よって、POSTパラメータとなると2つのパターンの前者ではOP、後者ではOP/RP両方でログアウト機能に関連するHTTP CookieのSameSite属性を意識する必要があります。

そう言えばチャチャッとSameSite属性毎の挙動を確認するためのツールを用意しましたので良かったら記事を読んでみてください。 medium.com

また、ログアウトしますか？のようなユーザーインタラクションを省略すると今度はトラッカー判定の方にも関連してきそうなので、この辺りの仕様とブラウザのHTTP Cookie, トラッカー判定事情の関係は今後も注意深くみていく必要がありそうです。

まとめ

RPからOPへのログアウト要求を送る方法が定義されている
OPからRPに戻るかどうかで2種類の挙動がある
POSTの場合はHTTP CookieのSameSite属性に気を付けろ

昔SessionManagementあたりのサンプル実装をしたことがあったのですがどっか行ってしまったので、またどこかのタイミングで動作確認ができる環境を用意したいと思います。

ではまた！

f:id:ritou:20200821032656p:plain