パスキー導入検討 (1) 採用スタイルと対応環境

ritou です。

今年2023年、いよいよパスキーが本格的に利用され始めるとお考えの方もいらっしゃるでしょう。 果たして「パスワード認証に代わりパスキーが使われ、パスワードレスな時代へと突入する」という予想は現実的なのでしょうか? この記事ではサービスにパスキーを導入するために最初に何を考える必要がありそうかというところから整理していきます。

ここではこれまでパスワード認証やID連携(ソーシャルログイン)を利用してきたサービス、それらと同様の新規サービスあたりを想定しています

パスキーの採用スタイル

「ユーザー認証の方式としてパスキーを採用する」と言っても、いくつかのスタイルがあります。

  1. メインの認証方式として採用
  2. オプショナルな認証方式として採用
  3. 採用しないが、採用しているIdPとID連携する

サービスがパスキーの恩恵を受けるために、どのスタイルを採用するかを最初の方で考える必要があるでしょう。

1はまさに「パスワードを置き換える」というイメージに近いかと思います。 これが理想な姿であるのでしょうが、これを実現するためにはサービス、アプリが必ずパスキーが動作する環境にある、もしくは対応している端末と接続できるような環境である必要があります。

2は他の認証方式との組み合わせのイメージです。

  • 1を目指す上で徐々に移行
  • 認証強度の高いIdPとのID連携がメイン、それを使いたくない/バックアップ用途としてユーザーが利用

などがこれに当たるかと思います。

1,2のいずれかが採用スタイルになるかと思いますが、あえて3を追加しています。 FIDOアライアンスのセミナーなどではID連携との関連はあまり語られていませんが、ユーザー認証の設計ではID連携も含めて検討する必要があるでしょう。

  • ID連携機能を提供するIdP
  • ID連携機能を利用するRP

と言う、ID連携の登場人物それぞれにおいてパスキーを採用するメリットがあります。

  • IdPがパスキーを採用 : パスキーで保護されたユーザーの情報をRPに利用できる
  • RPがパスキーを採用 : IdP上のアカウントBANや障害時など、ID連携が利用できない状態のリカバリー手段としてパスキーを利用できる

パスキーの文脈と混乱しがちですが、ID連携の文脈でApple/Google/Microsoftなどプラットフォーマーのアカウントはリスクベース認証や同一プラットフォームに接続されている他の端末を利用した認証機能など、認証強度やアカウントリカバリーの面で優れていると言われています。 そのようなプラットフォーマーではないIdPでも、パスキーを採用することでIdPのアカウントがフィッシング耐性を持てるのであれば価値向上につながると言えるでしょう。また、パスキーに対応したIdPがn個のRPと接続している状況ではそのRPのサービスもその恩恵を受けられることになります。

RP側としても上述の強度の高いIdPとID連携している場合、何かあった際のリカバリーのための認証方式としての採用が考えられるでしょう。 このようなID連携の話をする場合は "acr" や "amr" などを用いてIdP-RP間で認証強度や認証方式に関する情報までやりとりすべきであると声を大にしてずっとずっと言って来ました。今回のパスキーあたりは良い機会になると思うのでIdPを実装している開発者は考慮していただきたいと思います。

対応環境についての検討

上述の採用スタイルのうち、自分のサービスはどれに当たるのか、これで行きたいと決める際に、対応環境について確認、検討する必要があります。

  • サービスを提供する環境について対応状況は十分か?
  • 非対応環境での代替手段はあるのか?

昨年末に行われたFIDOアライアンスのセミナーでも、「(サービス名、会社名)はiOSでのパスキーサポートを表明しました!」みたいな発表がありましたよね。 例えばiOSアプリのみ提供、OSのバージョンが高く、制限があるAppleアカウントがあまり使わないようなサービスであれば、Appleアカウントによるバックアップが取られている=パスキーがサポートされていることがある程度保証されていると言えるでしょう。

悩むのは非対応環境が様々なレイヤで存在するケースですね。 例えばWebアプリケーションの場合、

  • プラットフォーム
  • 端末(ロック解除方法がどの程度用意されているか)
  • ブラウザの種類、バージョン(WebAuthn, DiscoverableCredentialsなど)

などで実際使えるユーザーがどれぐらいいるのか、使えるとしてもロック解除を使うUXがまともかどうかというのを検討する必要がありますね。現時点において、メインの認証方式として採用できるような状態にあるサービスはまだ少ないかと思います。 今後のパスキーを取り巻く状況の変化によりますが、採用スタイルとしては2を選びつつ、サービスによって1にできるかどうかを引き続き検討していく形になるのかなと思います。

まとめ

  • パスキーの採用スタイルを整理した
  • 対応環境と採用スタイルの関係を整理した
  • ID連携との組み合わせも考えるべき

というところですかね。 次回はプラットフォームアカウントとのID連携とプラットフォームアカウントにバックアップされているパスキーの似ているところ、違うところを整理しましょう。

ではまた。

IDaaSの認証機能でID連携を利用することをおすすめする理由

ritouです。

"Digital Identity技術勉強会 #iddance Advent Calendar 2022" 13日目の記事です。

qiita.com

現状、Digital Identityを専門とするような開発者がいないような場合に新規サービスを立ち上げようと思ったら、Auth0やFirebase AuthenticationのようないわゆるIDaaSを利用するのも選択肢として上がるでしょう。

いわゆるID基盤的なものを0から設計、実装できるような 俺の考える最強の...みたいなの を既に見つけてる感じの人からすると「ちょっと違う」「凝ったことやろうとすると機能というか自由度が足りない」「帯に短し襷に長し」みたいな意見が出ることもありますが、現状だけではなくDigital Identity分野の今後のトレンドを追いつつ機能追加していくみたいな長い目で見た時にはそれなりに有用なものであると思います。

今回は そんなIDaaSをおすすめするに至る考え方みたいなところ を紹介します。 内容はほとんどが 個人的な考え なので、解説記事のようなものが多い Zenn ではなくここに書いています。

1. 認証機能の自前実装よりもソーシャルログイン/ID連携

まずはここからです。いつも言ってるやつですね。

そういえば今年、10月に DroidKaigi 2022 というカンファレンスでお話をしてきました。

speakerdeck.com

前半はユーザー認証の現状に至るまでの経緯的な部分を自分の目線でまとめたもの、後半は手元のスマートフォンを用いてログインする仕組みについて紹介しました。

パスワード認証 -> リスト攻撃に対するTOTP -> スマホアプリを使ったPush通知を用いた認証 -> それらでも防げないフィッシングに対抗できるFIDO認証からパスキーへみたいな複雑な流れを側で見てきた身からすると、現世において1からユーザー認証機能を実装して運用することは大変に難しくなっていると言えるでしょう。

これまでWebアプリケーションの認証機能を実装する方法としてよくこんな分類をしていました。

  1. 何もない状態から設計/実装していく
  2. 採用しているプログラミング言語のWebアプリケーションフレームワークやライブラリを利用する
  3. 外部のSaaS(今回のIDaaSもこれ)を利用する

1で多要素認証やリスクベースなしくみを考えるには私みたいな専門家ぶったエンジニアを雇う必要があります。 となると2のように既にあるものを組み合わせていくかとなるところですが、パスワード認証 or ソーシャルログインぐらいしかなかった時代に比べて、実現したい認証機能のどこまで実現できるのか、自分が想像する挙動になるかどうか良く調査、検証した上で実装していく必要があるでしょう。となると、3でしっくりくるサービスがあったらそれを使うのも一つの手ですね。

また、2や3でも、最近は普通にソーシャルログインやID連携とよばれる機能を "普通に、そこそこ安全に" 実現できる仕組みが増えてきました。深く考え始めるとキリがないユーザー認証方式の設計について考えるのはもう大手のところに任せ、ソーシャルログイン/ID連携と呼ばれる方法でそれらのユーザー情報を利用する方が開発/運用コストともに良さそうです。これは今後パスキーのようなどんな安全な認証方式が普及したとしても変わらないどころか、より安全なIdPやユーザーが使いたいIdPを選んでID連携するような世界に近づくのかなと思っています。

2. 認証以外にもあれこれ必要なID管理機能

ソーシャルログインでユーザー認証機能が実装できたところで、そもそもそれだけ実装したらいいわけでも無いのが実情です。 新規登録から退会まで、いやその先もまだあるかも知れませんが、いわゆるID管理といった機能が必要となります。 昔は良い意味での疎結合的な割り切りで各種トークン取得のところまでしかしないライブラリがあってそこと自前のID管理の仕組みをつなぐ必要があったりしました。今はそれなりに改善されてつなぎも楽にできるものがありそうですが、ここで変な実装をしてしまうと後で困ることになります。

この辺りは以前、記事を書きました。

ritou.hatenablog.com

ID管理における状態遷移と言ったらイメージしやすいかも知れませんが、ある程度ちゃんとしたサービスを作ろうと思うとこのIdentity Lifecycle というものを意識する必要があります。 とはいえ、この辺りはサービスに必須である機能ではあるものの、サービスが提供したい本質とは異なります。これにどれだけコストをかけられるのかを考えると、自前でやるよりもこの辺りをまとめて面倒見てくれる外部のサービスを利用した方がいいってなりますよね。

そこでIDaaSでしょうとなるわけです。 むかーしからあるmBaaSみたいにアプリのバックエンドに必要な機能を全部SaaSに任せろとは言いません。ざっくりID周りだけ頼む、他は自分たちで頑張るからってのができるのが最近のIDaaSの良い面であると思います。

3. 独自認証の選択肢、将来的な機能追加まで考える

さっきはソーシャルログインだけでいいって言いましたが、他にもありました。ごめんなさい。

ID連携って言うと、どうしても "IdPに何かあったら" "結局自前でも認証機能が必要なんじゃないの?" みたいな話が出てきます。 IdPやってるようなところが急になくなるとは考えられません(Twitterみたいに不安になることはあるかも?)が、そこのログインが一時的に止まったり、アカウント単位でBANされたりは想定しておく必要はあるでしょう。 サービスの内容によっては、その時にアカウントリカバリー用途として別の認証機能と設定変更の機能が必要になるでしょう。最近だと、TwitterでZennのGoogleアカウントの切換機能を目にしました。まさにこれの話です。

Zenn の場合は専用のメールアドレスを利用した認証を行った上でGoogleアカウントの切換と言う設定変更の機能が提供されるわけです。

IDaaSにはID連携だけではなく他の認証方式も最初から利用できるものや、その選択肢にない場合に拡張可能なところもあります。また、今はなくてもこれから勝手に対応してくれるものもあるでしょう。

最近だとパスキー/Paskey/passkeyと呼ばれる仕組みが話題ですが、IDaaSの中にも早い段階で実装してくるところ、時間がかかるところがあると思います(例えばAuth0は早そう)。

auth0.com

現在のFIDO2(WebAuthn)と呼ばれるあたりの扱いにおいても既に実装されていたり、カスタム実装で実現可能なところなどがあると思います。IDaaSの機能を利用して安全な認証方式が利用できるのであればアカウントリカバリーもしくは利便性向上あたりでID連携と併用して実装するのもありだと思います。 初期の機能開発におけるコストだけではなく、運用コスト、将来的な機能追加まで見据えてIDaaSの採用も検討してみるのも良いと思います。

PR ちょうど良い本、あるよ

そういえば "Firebase Authenticationで学ぶ ソーシャルログイン入門 ID管理の原則にそった実装のベストプラクティス" とかいう本が 昨日2022/12/12に発売された らしいです。

@authyasan が今回の記事のような話を実際に手を動かしながら実感/理解できるように書かれた本です。

自分も監修としてたくさん意見をお伝えして参考にしてもらったので、あれこれどっかで見たことある考えや言い回しだと思ってもらえるかと思います。良かったら読んでみてください。

明日のアドカレ

ついに @phr_eidentity さんの登場ですね。 DID/VCあたりの最新のお話が聞けそうです。

qiita.com

ではまた!

idcon29のY!Jの事例からログインフローにおけるWebAuthn対応の課題を考えた

ritouです。

idcon の Yahoo! JAPAN の人の資料と動画を見たメモです。

www.docswell.com

youtu.be

2画面のログインUX

p5

2画面か一回でやるかの話は、個人的にこだわっているスキャンの話もありますね。 Y!JはFederation(RP側)をやっていませんが、マネフォのようにパスワード認証/FederationがあるところにWebAuthnを追加する場合にどうすべきか、みたいなのは別途どこかで整理したい気がしています。

推測

Platform Authenticator だけはなく YubikeyとかのRoaming Authenticatorに対応してる場合、リセットした場合も同じことが起こりそう。 そもそもFIDOはブラウザ - 認証器と多段の処理になっているのでブラウザレイヤーでの完全なコントロールってのも難しそう。 例えば、AndroidChrome -> Firefoxと使っていくとCookieなどではFIDO使った形跡がないけど認証器は使えるみたいな場合があることは知られている。

BackupState

p20

複数登録させないと問題については、この値があるCredentialIdは一つでいいけど、ないやつは複数登録させたいみたいな気持ちにはなりそう。

そういえば、FIDOアライアンスが出してたこの動画にある、AndroidでcaBLE使ってログインした後にWindows側のpasskey作るみたいなUXについて、passkeyがここまでやってくれるみたいなのとこれまでのFIDO認証のプラクティス(Platform Authenticatorのある環境なら登録させちゃう)と干渉してしまう部分はありそうなので、これが更新されてどうなるのかにも注目しています。

www.youtube.com

Conditional UI 万能?

これ便利そうで注目しているものの、なんとなくですが、こいつを認証方式の分岐の主役として使うのは思うよりも難しいのかなーと思ったりします。 非対応のブラウザもあるし、Roaming Authenticatorの扱いは難しい。となるとやはりショートカットやユーザーが他の認証方式を選択した後にWebAuthnに戻ってくる経路として使う感じがいいのかなと思ったりします。

Conditional UIの課題

p39

サービス側で削除しても、認証器側ではまだ有効っぽく振る舞われる問題に関して、ユーザー識別を先にやるパターンでは excludeCredentials が使えるかもしれません。

ベターなUX

p40

この辺、Y!Jのような最短経路を提供しようと思うとなかなか困難なところはあると思います。

  • まずはベタベタなユーザー選択式のUXを用意、とにかく詰まらないように網羅的な経路を用意
  • Cookieとか前回のなんとかで推測がいけない訳ではなく、Conditional UIみたいなのはショートカットとして使っていく
  • 推測失敗やユーザーの選択ミスでこの方式が使えないみたいな残念体験は一定数存在すると想定し、そこからフォールバックの経路をしっかり用意する

ぐらいでどこまで精度を上げていけるかなのかなーと言うところですね。

こう言うのをまとめてpasskey対応とか言うのをヘルプとかで説明するの大変問題 がある。

質問 : クレデンシャル共有

合法、違法問わずパスワードでも公開鍵暗号方式でも共有されている世の中なので使われそうな気はするがサービス側の扱いは変わらなそう。

質問 : 乗っ取りリスク

これはFederationでも通ってきた道だとは思うが、ポリシー判断の際はこれまでのFIDOよりは扱いが下がるかもしれない。 金融機関で使いたい時にプラットフォーム側にAAL2以上を要求、みたいな話は難しそう。

(追記ここから) ↑をちょっと補足すると

(追記ここまで)

他にもあった気がするけど一旦ここまで。

個人的にはもうちょっと Discoverable Credentialsについての細けぇ議論があったら面白いかなと思いました。displayName変えられないとかポツポツあったけど。

ではまた。

フィッシング対策観点でメールでリンクが送られない世界を目指すために我々は何ができるか

ritou です

急に寒くなりましたね。

この記事は何の話か

最近のメール経由のフィッシングの話で、

  • その辺のユーザーにとって、メールの送信元が正規のものかどうかの確認は容易ではない
  • さらに、メール本文に含まれるURLの確認が容易ではない

という現状があります。

前者がうまいこと解決されると一番良いんでしょうけれども、そうもいかないのでしょう? 後者のところでよく「メールに含まれる怪しいリンクをクリックしないでください」と言うのがあります。 そもそも怪しいかどうかがわからないからクリックするわけなので、「怪しい」部分を説明するのも大事なことですが、細けーことは一般ピーポーには無理なので、「メールに含まれるリンクをクリックしないでください」まで振り切る方がいい気がしてます。

しかし、これはこれで

  • サービスはユーザーとのコミュニケーションツールとしてリンクを送る(クリックして欲しい)
  • ユーザーはメールのリンクをクリックせずに、お気に入りなどからサービスにアクセスして内容を確認してください

という不整合が起こり、サービスが期待する処理をユーザーが進めてくれないという事案にもつながりかねません。 こんな状況よりは、

  • サービスがメールを受け取れるユーザーにのみ可能な処理を行わせるためにリンクを送る
  • ユーザーがそのリンクをクリックして処理を続ける

というUXにリスクがある前提で話を進め、

  • メールをコミュニケーションのツールとして捉えるのではなく通知の仕組み程度の用途に止める
  • メールを受けた後にユーザーが適切に処理を継続させられるような誘導ができる世界を目指す

ような変化をしていくという方向性も検討する余地があるのではと思っています。

そこでこんなTweetをしてみました。

我々一般開発者がワーワー声を上げても基本的に何も起こらないもので、セキュリティに詳しい人の集まりでこの辺りが少しでも話題になることがあって何かしらの反応や動きにつながったら良いなと期待しております。

現状に対してこんなことしないといけないのでは?みたいな話はzennの記事で書きました。

zenn.dev

これの続き的な立ち位置で、今回は、 サービスがメールでURLを送ってユーザーがそれをクリックして何かの処理が行われるようなフローをなくすために何が必要なのか をもう少し考えてみます。

そもそもメールでリンクが送られるのはどんな時?

色々あるとは思うんですが、大きく分けて2種類あるかなーと思っております。

  • メールを受け取れるユーザーにだけ次の処理を許したい
    • パスワード再設定リンクを送信
    • マジックリンクでログイン
  • 何かを伝えたい
    • メッセージを受信しました + リンク
    • サービスからのお知らせとか + リンク

他にあったら教えてください。

代替案

メールを受け取れるユーザーにだけ次の処理を許したい : リンククリック -> OTP送信

「メールを受け取ったことを確認したければ、OTPを送ればいいじゃない」 という案です。

OTPを使うと、厳密には「今画面を操作しているユーザーがメールを受け取ったこと」を確認できるのでいわゆる経路外認証としてログインで使われていたりもします。 あと、動線がメール受信後のリンククリックの後にで分かれてしまうのも避けられるので、使い所によってはその後の繋ぎが便利になるかもしれません。 面倒な点といえばOTPのコピペですが、そこはWebOTPで頼む、ということですね。

何かを伝えたい : サービス内コンテンツへの誘導リンク送信 -> お気に入りなどから確認を促す

これもよく言われていることですが、実際は結構辛い気がします。 お気に入りからって言いますけど、お気に入りそんなにちゃんと使われてると思いますか? ってことで、この辺りもう少しいい感じにできないのかなーと前に思ってたことを思い出しました。

まずはブラウザについてですが、例えば Google Chrome とかだとブランクなページを開くと最近使ってたサービスみたいなのを表示してくれたりしますよね。自分ので試したら Gmail / Twitter / GitHub / 自分のブログ ... みたいな感じでした。これも履歴みたいなもんではありますが、このようにざっくりでいいのでサービス単位の管理ができれば良いのでは?と思います。

その上で、サービスは次のような自サービスのメタデータを定義しておき、そこにリンクできる HTTP Header なり meta タグなりを仕込みます。 メタデータの扱いについてはこれまでもいくつかのWeb標準APIなどで利用しているものもあると思いますし、それを束ねる仕組みもできそうです。

あとはブラウザはそのメタデータを読み込みに行ったりキャッシュしたりして、ユーザーを期待するページに誘導可能なのではないか?と言う案です。

  • トップページ
  • お知らせ一覧 : 重要なお知らせがあることをメールで通知しつつここから誘導を試みる
  • ヘルプ / 問い合わせ
  • 利用規約 / プライバシーポリシー : ●●が変わりますメールを送りつつ実態はここから誘導を試みる

画像はイメージです。

なんとなく、こんな感じならお気に入りよりももうちょっとなんとかなるんじゃないか、そうでもないかも、みたいな感じですね。

まとめ

  • フィッシング対策とサービス側の意識の違いなんとかならんか
  • メールからリンクを無くす方法を考えてみた
  • なんだかんだでメールをコミュニケーションツールから通知ツールに格下げしようとしている私をお許しください

以上です。

はてブのコメントどうもです!

サービス登録機能はあるといいなと思うけどiGoogleがまだあれば、ほしかったなと思う気持ちがある

サービス管理のあたりは確かにあの頃欲しかったところですね。

URL入らなくなったらユーザサポートめんどくさくなるなぁという感想。

確かに、ユーザーサポートの負担を上げずに実現できる方法はもうちょっと探っていきたいところです。

今回はメールも通知目的に全振りしてはどうかな話なので、例えば今のSMSで送られる情報ぐらいには最小化できるのでは? という意図で書いています。

ヘルプデスク的な業務もしてる自分としては、FAQのここ見ろやバーンってURLを送りつける機能は残してもらいたい。

これも同意ですが、バーンと送られ的たリンクをクリックしないでください!みたいな現状は切ないので、正規のサービスとの繋ぎの部分はもう少し考えていきたいところです。

FedCM入門 その2 ~ 現状のFedCM実装解説

おはようございます。ritouです。 前回の記事に引き続き、FedCM入門です。

ritou.hatenablog.com

何の話か

6/21(火) 19時から、OpenIDファウンデーション・ジャパン主催のイベントがあります。

openid.connpass.com

明日じゃん。

これに先立って、Federated Credential Management API(FedCM) について 非公式 の入門記事を書いています。 今回は、FedCMの現状の実装について解説します。

それでは始めましょう。

登場人物

FedCMの登場人物は、わりと一般的なID連携のものと同じです。

  • IdP : Identity Provider. 他サービスに対してユーザー情報を提供する サービス
  • RP : Relying Party. IdPのユーザー情報を用いて認証機能を実現する サービス
  • ユーザー : IdP/RPそれぞれを利用するユーザー
  • ブラウザ : FedCMに対応したブラウザ

ID連携フロー

FedCMはGOALとしてOpenID Connect(OIDC)/SAMLを対象にするとか言ってましたが、今のところは RP上にID連携のためのプロンプトを出してOIDCを簡略化したような仕組みでユーザー情報を受け渡してログインさせる というのが実装されています。 言い換えると、現在のFedCMで実装されている機能はGoogleが提供するOne Tap Sign-In and Sign-Up(Twitter, Medium, 他いろんなサービスでGoogleアカウントでログインするか?って出てくるやつ)相当である ということです。

developers.google.com

はじめにFedCMを用いたID連携の流れをざっくり説明します。

  1. ユーザーはIdPにログインしている前提
  2. ユーザーがRPで "IdPでログイン" を利用しようとして、RPはFedCMのAPIを呼び出す
  3. ブラウザはIdPに対してログイン中のアカウント情報(リスト)を要求し、ID連携のためのプロンプトをRPドメイン上で表示する
  4. ブラウザはユーザーが選択したアカウント情報に紐づく認証用トークン(OIDCのIDToken)をIdPに要求し取得したものをRPに渡す。RPはそれを認証機能に利用します。

まず前提として、1. でユーザーがIdPにログイン中である必要があります。一般的なWebアプリケーションのような単一ユーザーがログインできる仕組み、もしくはGoogleのような複数アカウントでログインできる仕組みにも対応しています。

プライバシー保護の観点から、RPが"IdPに誰がログインしているか、誰もログインしていないか" を知りえる状態は良くありません。現状、IdPに誰もログインしていない場合は、RPがFedCMのAPIを呼び出しても汎用的なエラーのみが返されます。この辺、FedCMのユースケースはまた別途考察しようと思っているところですが、実際は ログイン中のユーザーがいる状態のID連携の利便性を上げるショートカット 的な感じに使われることになるのかなーというところです。

2でFedCMのAPIを呼び出す部分はこの後説明します。

3で出てくるプロンプトですが、あるユーザーが単体でログイン状態の場合は次のような画像となります。(私のメアドは公開されてるようなものなのでよし)

「続行」をユーザーがクリックすると、User-Agent は IdP にリクエストが送られ、RPにユーザー情報+認証イベントの情報を含む IDToken (具体的な内容はIdP依存だけど実質OIDC互換)が渡されます。

Googleのように同時に複数アカウントがログインできる仕組みの場合、この画面の前にアカウントリストから選択するプロンプトが入ります。

4ではRPはそれを使ってよしなにログインするなり新規登録するなりをします。ここはRPの要件に依存します。

FedCMではID連携フロー以外にログアウトだったりIDToken無効化(退会?)のリクエストを送ることも可能ですが、現状としてはここをまずおさえておけばいいでしょう。

ID連携のシーケンス

ここまでざっくり説明したFedCMのID連携フローで、実際何が行われるかは公式ドキュメントで公開されています。

developer.chrome.com

シーケンスは以下の通りです。

この図だけで大体わかっちゃう人がいたら是非一緒に働きましょう。

ここからは、公式のドキュメントや自分で作成したRP/IdPの動作例を用いて説明していきます。

0. ブラウザがFedCM対応環境環境かどうかを確認する

実際のID連携のプロダクトでは、FedCMが有効ではない環境のフォールバックも当然必要です。

  • FedCMが対応環境ならば優先的に利用
  • 非対応環境ではこれまで通りのID連携

みたいなところを自然なUXで提供する必要があります。

現状では、RPは以下のコードでFedCMのID連携フローが利用可能かどうかの判定ができます。 FedCMの名前にもなってる FederatedCredential っていう仕組みは既にあるものなので、それとloginが実装されているかを組み合わせで判定します。

if (window.FederatedCredential || FederatedCredential.prototype.login) {
  // If the feature is available, take action
}

ちょっと話はずれますが、個人的に現在の One Tap sign-in and sign-up は未ログイン状態の時にプロンプトを節操なく出してくる印象があるんですが、それと同様ではなくログインや新規登録のフローに入ったときに絞るなどの検討が必要かなという印象です。

1. RPがFedCMの関数を呼び出してID連携を要求

RPがFedCMのID連携を開始する処理は navigator.credentials.get の呼び出しから始まります。 ここでRPはIdPのURLと自分自身の識別子(clientId)を指定します。

const credential = await navigator.credentials.get({
        federated: {
          providers: [{
            url: 'https://ex-fedcm-idp.herokuapp.com/',
            clientId: 'https://ex-fedcm-rp.herokuapp.com/'
          }]
        }
    })

上記サンプル実装では、clientId にRP自身のURLをそのまま実装していますが、これはIdPが提供するClient登録機能などで払い出しされた値を指定することになります。 ちなみに、providers とあるように、ここでは複数のIdPのアカウントとの連携も視野に入れられているように見えますね。 現状の実装としては、最初の1個を読むようになってるような挙動をしていますが、ここで複数が指定されるようになったら一番最初に "プロバイダ選択" みたいなプロンプトになるのかなーという想像をしています。

FedCMではここから FederatedCredential.login() を呼び出すことでRPはブラウザはID連携の処理を開始します。

const nonce = '65a7c572-b4fc-4e27-b899-c67e12ac36a5';
const { id_token } = await credential.login({ nonce });

ここでOIDCにおける nonce パラメータを指定することで、ブラウザがIdPから取得してRPに渡されるIDTokenがこのセッション/リクエストに紐づいていることを検証可能です(いわゆるCSRF/リプレイアタック対策みたいな話)。

ブラウザがIdPに送る最初のリクエストは "Top level domain manifest" と記載されているリクエストです。

GET /.well-known/fedcm.json HTTP/1.1
Host: ex-fedcm-idp.herokuapp.com
Accept: application/json
Sec-FedCM-CSRF: ?1
$ curl "https://ex-fedcm-idp.herokuapp.com/.well-known/fedcm.json"
 -H "Sec-FedCM-CSRF:?1"
 -H "Accept:application/json"
{"provider_urls":["https://ex-fedcm-idp.herokuapp.com/"]}

ここでは、RPが指定したIdPのURLがFedCMに対応しているか、リクエストを送っても良いかどうかを確認します。いわゆるマルチテナントなIdPなどでは provider_urls の値が複数返されることになります。

その後に、ドキュメントで "IdP manifest file" と記載されているエンドポイントにリクエストが送られます。これは IdP で指定されたURLにある "/fedcm.json" というエンドポイントです。

GET /fedcm.json HTTP/1.1
Host: ex-fedcm-idp.herokuapp.com
Accept: application/json
Sec-FedCM-CSRF: ?1
$ curl "https://ex-fedcm-idp.herokuapp.com/fedcm.json"
 -H "Sec-FedCM-CSRF:?1"
 -H "Accept:application/json"
{"accounts_endpoint":"/accounts",
 "branding":{"background_color":"0xFF4500","color":"0xFFFFFF","icons":[{"size":32,"url":"https://ex-fedcm-idp.herokuapp.com/images/icon_32.ico"}]},
 "client_metadata_endpoint":"/client_metadata",
 "id_token_endpoint":"/id_token"}

このレスポンスには各種エンドポイントとプロンプトを出す際のアイコンや色といった情報(branding)が含まれます。

ブラウザはこの後、プロンプトに表示する Client 情報(利用規約、プライバシーポリシーのURL)を要求するために "client_metadata_endpoint" にリクエストを送ります。

GET /client_metadata?client_id=https%3A%2F%2Fex-fedcm-rp.herokuapp.com%2F HTTP/1.1
Host: ex-fedcm-idp.herokuapp.com
Referer: https://ex-fedcm-rp.herokuapp.com/
Accept: application/json
Sec-FedCM-CSRF: ?1
$ curl "https://ex-fedcm-idp.herokuapp.com/client_metadata?client_id=https%3A%2F%2Fex-fedcm-rp.herokuapp.com%2F"
 -H "Sec-FedCM-CSRF:?1"
 -H "Referer:https://ex-fedcm-rp.herokuapp.com/"
 -H "Accept:application/json"
{"privacy_policy_url":"https://ex-fedcm-rp.herokuapp.com/pp",
 "terms_of_service_url":"https://ex-fedcm-rp.herokuapp.com/tos"}

RP じゃなく IdP が RP の metadata を出す というところがやや引っかかりますが、まぁいいでしょう。ここで返されたURLはプロンプト内でリンクとして使われます。

また、このリクエストには当然 client_id の値が含まれますが、この後の Accounts list endpoint へのリクエストには含まれません。 IdPがClientの検証を行うには、この段階で client_id パラメータと Referer ヘッダあたりを利用して検証する必要がありそうです。

次に、ブラウザは Accounts list endpoint に現在ログイン中のアカウントリストを要求します。

GET /accounts_list.php HTTP/1.1
Host: ex-fedcm-idp.herokuapp.com
Accept: application/json
Cookie: ...IdP's Cookie...
Sec-FedCM-CSRF: ?1
$ curl "https://ex-fedcm-idp.herokuapp.com/accounts"
 -H "Sec-FedCM-CSRF:?1"
 -H "Referer:https://ex-fedcm-rp.herokuapp.com/"
 -H "Cookie:..."  -H "Accept:application/json"
{"accounts":
 [
   {"approved_clients":[],
    "email":"ritou.06@gmail.com",
    "email_verified":true,
    "family_name":"Ito",
    "given_name":"Ryo",
    "id":"google_user_114181308725730985237",
    "name":"Ryo Ito",
    "picture":"https://lh3.googleusercontent.com/a-/AOh14GjQ_fcwsIRk6LalbnjCHWzWfk7BkYvX9XAkZP8b8Q=s96-c"}
 ]
}

注目するべきは、ここで1st Party相当のCookieが送られます(6月頭の時点ではSameSite=None(3rd Party相当)のものが送られるようになっているので Issueで連絡済みでしたが今確認したらStrictでもいけました!) RPはFedCMのAPIを利用するだけで、IdPも1st Party相当のCookieのみで利便性の高いID連携を実現できるのがポイントですね。

レスポンスにはログイン中のユーザーリストが含まれ、ユーザー情報としてはユーザー識別子、メールアドレス、名前、プロフィール画像などが返されます。

2. ブラウザがユーザーにIdP/RPのアカウント情報、

概要で説明した通り、ここで複数のアカウント情報が返されたらブラウザはリスト表示、単一の場合は同意のプロンプトを表示します。

3. ブラウザがIdPにIDTokenを要求

ユーザーがブラウザのプロンプト上でID連携することに同意したら、ブラウザはIdPに対象ユーザーのIDTokenを要求します。このリクエストにもIdP向けのCookieが含まれます。

POST /id_token HTTP/1.1
Host: ex-fedcm-idp.herokuapp.com
Referer: https://ex-fedcm-rp.herokuapp.com/
Content-Type: application/x-www-form-urlencoded
Cookie: ...IdP's Cookie...
Sec-FedCM-CSRF: ?1
account_id=google_user_114181308725730985237&client_id=https://ex-fedcm-rp.herokuapp.com/&disclosure_text_shown=true&nonce=1c64ca07-90f8-4eee-b3d4-d0eb871ea816

IdPは対象ユーザーのIDTokenをJSON形式で返します。

{
  "id_token": "eyJ********"
}

4. RPはIDTokenを受け取って認証処理などを行う

RPはブラウザから受け取ったIDTokenを利用して認証処理を行います。 呼び出したときのコードを振り返りましょう。

const nonce = '65a7c572-b4fc-4e27-b899-c67e12ac36a5';
const { idToken } = await credential.login({ nonce });

ドキュメントには { id_token } とありますが現状のChrome Canaryの実装では { idToken } で取得できます。これもそのうち治るでしょう。

この辺りは、RPにとっては、OIDCのImplicit Flowと呼ばれるものと同等の処理です。 細かい違いについては別記事で説明予定ですが、OIDCのIDTokenはJWT形式の文字列であり、次のステップを踏むことで検証できます。

  1. 署名が正しい
  2. iss パラメータがIdPのものである
  3. aud が自身のものである
  4. exp が有効期限内である
  5. nonce が "1. RPがFedCMの関数を呼び出してID連携を要求" で指定したものである

このような検証ステップを終えたら、RPは自サービス内のログインや新規登録処理を行います。

まとめ

今回はFedCMのID連携のフローで送られるリクエスト/レスポンスを説明しました。 ユーザーからの見た目はプロンプトが表示されてそこからID連携が行われるだけですが、裏側でいくつかの処理が行われています。

ここまでの流れはAndroid/PCの新しいChrome Canaryで動作確認できます。

興味があったら試していただいて、気になることがありましたらコメントしてください。

次回予告

現状、FedCMは OIDC寄り の仕様になっているものの、ブラウザ-IdP間のリクエスト/レスポンスはFedCM独自のものです。 特に既存のOIDC IdPの方がこれに対応した実装を行う必要がありますが、そのためにはOIDC/FedCMの仕様間のFit/Gapを整理する必要があります。 例えば、ブラウザのCookieを受け取りつつレスポンスの形式はJSONであるみたいな仕様はOIDCの仕様ではあまり馴染みがないものです。

そこで、次回は

  • RPがID連携を要求する部分、OIDC準拠に近づくにはどうなるべき?
  • OIDC IdPが楽にFedCMに対応するための考え方、違う部分についてはFedCMの仕様がこうなっていると捗る、もしくはOIDCにこのような拡張があると捗る

みたいなところを紹介します。

ではまた!

FedCM入門 その1 ~ ID連携の課題とFedCMのアプローチ

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

何の話か

6/21(火) 19時から、OpenIDファウンデーション・ジャパン主催のイベントがあります。

openid.connpass.com

ここで取り上げられるFedCMについて、3部作ぐらいで 非公式解説 を書いていきます。

  1. ID連携の課題とFedCMのアプローチ 今回はこれ
  2. 現状のFedCM実装解説
  3. FedCM vs OIDC 仕様の差分、RP/IdPの対応、差分解消案

上記イベントでの自分の発表内容は2,3あたりになる予定です。

FedCMとは

FedCMについては、4月末ぐらいにいろいろなドキュメントが公開されました。 英語が読める方はこんな非公式情報を信用せずに、公式なドキュメントを読みましょう。

developer.chrome.com

FedCMで解決したい課題

現在、OpenID ConnectやSAMLを用いたID連携はわりと普及してきましたが、いくつか課題や懸念点があります。 FedCMではID連携で使われているiframe, redirects and cookiesあたりの技術がトラッキング用途のものと区別できないことを問題視しています。

Unfortunately, the mechanisms that identity federation was designed on (iframes, redirects and cookies) can also track users across the web. As the user agent isn't able to differentiate between identity federation and tracking, this makes it difficult to determine when these mechanisms are being used to support identity federation

ID連携の基本動作として、ID連携を利用するサービス(Relying Party, 以下RP)とID連携を提供するサービス(Identity Provider, 以下IdP)の間のリダイレクト、いわゆる「OAuth Dance」があります。 例えば私は Zennに記事を書いております が、Googleアカウントでのログインを始めると一度IdPであるGoogleに遷移してGoogle自体にログインしたり、ログイン中のユーザーからID連携に利用するユーザーを選択したりします。そしてID連携の際にRPに提供される属性情報やリソースアクセスに同意した上でRPに戻ってくるお馴染みのフローのことです。 開発者であれば何が行われているかを割と直感的に理解しやすいかもしれませんが、一般ユーザーはそうではないかもしれません。

このようなID連携フローの利便性を上げるため、いくつかの手法が考えられてきました。 確か2009年とかその辺り...スマホが現在のように普及する前のPC主体の頃、Googleでログインというボタンを押すとポップアップで小さめのGoogleの画面が出てきてログインやユーザー情報の提供への同意が求められ、終わったらそれが閉じて元の画面がログイン状態になるみたいな挙動が実装されました。 なんとなーくおしゃれな感じに立ち上がってくるモーダルの中でログインさせるのではなく、ちゃんとURLを確認可能にする、UIも小さな画面に最適化しつつ現在のログインユーザーやRPに渡される情報などをもれなく表示するといったUX検討が行われ、大手IDプロバイダのSDKなどで実装されるようになりました。

一方で、スマホであればポップアップの挙動が変わるのでリダイレクトでやるしかないかーみたいな話も出てきました。 ID連携だけに止まらないですが、この辺りの利便性を上げる仕組みとして、ブラウザがサポート用のプロンプトを出すような流れが出てきました。 ID連携においてはRPにいる時点でIdPにログイン中のユーザーでログインしますか?みたいなプロンプトを出す仕組みをGoogleAndroidやWeb向けに提供しています。

developers.google.com

私は普段、複数のGoogleアカウントを区別するためにChromeのプロフィールを利用していますが、個人のアカウント以外のところでついうっかり(本当についうっかりです)TwitterのURLを開こうとする とこんな画面になったりします。

これはTwitterドメイン上でGoogleにログイン中のユーザー情報を含むプロンプトを表示し、ワンタップでユーザー情報をやりとりすることで利便性をあげようみたいな仕組みです。よく見ると、他にもmediumとかいろんなサービスで使われていますよ。

先に紹介したポップアップやこのOne Tapみたいな仕組みを実装しようと思うと、3rd Party Cookieとiframeあたりの話を避けては通れません。Googleのサービスであれば開発者はSDKを使うだけなので意識してなかったりしますが、One Tapもブラウザの設定で3rd Party Cookieをブロックすると動かなくなります。

また、ID連携の仕様の中にはRPとIdPの間でセッション同期、ログアウト同期を行うための仕様があります。これらもフロントチャンネルでの処理ではiframe + postMessage を利用しています。

と、ここまで紹介した3rd Party Cookieを利用する仕組みですが、似たような仕組みで広告周りでユーザーの特定や行動把握のために別ドメインとやりとりしたり、リワードのために一瞬Safariを開いてみたいな実装がよく行われてきました。あれもユーザー情報を同期して何かの最適化を行おうとするものですが、ID連携とは別物です。しかし、ブラウザから見た挙動としてはどうなのでしょうか。これらはとても似ていますというかほぼ一緒、区別できません。

昨今、各ブラウザにはプライバシー保護の名の下に3rd Party Cookieを利用する仕組みを減らしたりブラウザから取れる細かい情報を減らしたりする動きがあります。FedCMを含むChromeのプライバシーサンドボックス構想みたいなのもまさにそれです。しかし上述のとおりID連携の仕組みで3rd Party Cookieに依存するものがあるので、3rd Party Cookieが廃止された世界ではそれらは当然動かなくなります。これはなんとかしないといけませんってなるわけですね。

そこでFedCMですよという話です。

FedCMのアプローチ

FedCMの目的は「3rd Party Cookieを廃止してもID連携の仕組みが動く世の中にしよう。必要に応じてブラウザが仲介することでプライバシー面のリスク低減を目指そう」あたりにあります。

The Federated Credential Management API (FedCM) provides a use case specific abstraction for federated identity flows on the web. This purpose-built API allows the browser to understand the context in which the RP and IdP exchange information, inform the user as to the information and privilege levels being shared and prevent unintended abuse.

具体的には次回以降の記事で書く予定ですがざっくりと

  • ID連携にもブラウザが仲介するぞ!
  • RPはブラウザのAPIを呼び出してID連携を要求
  • ブラウザはIdPに対して1st Party Cookie相当のリクエストを送る
  • ブラウザはユーザーのアクション(ユーザー選択や利用の同意)に基づいてIdPから取得した情報をRPへ提供
  • ログアウトやID連携の無効化などもブラウザ経由でRPからIdPに伝えられるようにする

あたりがFedCMの現在のスコープとなっています。

ブラウザが仲介して1st Party Cookieとしてリクエストを行う部分については上記3rd Party Cookie廃止の流れへの対応そのものですが、IdPとしても他のドメインからセッションCookieを参照できなくできることはセキュアになるために喜ばしいことでしょう。 ユーザーアクションに基づいてRPに情報開示が行われる部分は既存とそれほど変わらない気はしますが、その辺り配慮してますと言うのはなんとなく伝わってきます。

実装面で言うと、WebAuthnやWebOTPも同様なのですが、ブラウザがプロンプトなりを出してくれる仕組みの場合はJavaScriptなどでしっかりSDKを作り込まなくても比較的容易にRPが実装可能(もちろんそれをラップしてSDKを提供するのはあり)と言うのが大きいでしょう。

現状のFedCMとChromeの実装状況について、ID連携と書いた部分については上で紹介した One Tap 相当の最低限のログインに必要なユーザー情報のやり取りが実現できるところまで実装されています。PC/Android版のChrome Canaryで動作しますので、次回の記事で紹介します。 正直、ここからOIDC/SAMLがフル互換で動く状態になるまでは時間はかかりそうですが、その辺りの考察も今後記事にする予定です。

次回予告

FedCMの現状の動作と裏でどのような処理が行われているかを説明します。

21日までに3つ記事出せるのだろうか???

ではまた!

FIDOの最新動向から考える巨大プラットフォーマーとの関係

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

Google I/O の "A path to a world without passwords" っていう発表、ご覧になりましたか?

www.youtube.com

FIDO, WebOTP, FedCM...いいネタ揃ってますね!今回はFIDOの話をしましょう。 パスワード認証はもう終わり!時代はパスワードレス認証ですよと言い続けてはや数年経ちましたが、最近こんなプレスリリースが出ていました。

prtimes.jp

すべての人にとってウェブをより安全で使いやすいものにするための共同の取り組みとして、AppleGoogleMicrosoftは本日、FIDOアライアンスとWorld Wide Web Consortium(以下、W3C)が策定した共通のパスワードレス認証のサポートを拡大する計画を発表しました。

何やら大ごと感ありますが、3行でまとめると

  • FIDOは指紋認証などのローカル認証と公開鍵暗号方式を組み合わせた仕組みである
  • FIDOの最大の特徴は それぞれの認証器(セキュリティキーもしくはPCなどの端末にしか存在しない秘密鍵 を利用することであるが、それ故にロスト時のリカバリーや新規端末利用(機種変更など)時に全ての利用サービスで再登録が必要ってところに課題があった
  • Apple, Google, MSなどがプラットフォーマーの強みを活かしてその辺うまく同期する仕組み作ったら課題も解決して便利になるな!ついでにだけど、パスワードに対してパスキーって呼ぶぞ!

といったところです。

1番目はおいておいて、2番目はこれまで段階的にホワイトペーパーなどが出ていた部分ですね。別記事で取り上げました。 今回は3番目を強く全面に押し出してパスワードレスやっていき!みたいなところを印象付けてきているように見えます。それ実現できたらすごいことになるよな!書かれている通り理想を実現できればな!そんなに上手く行かんだろうけどな! っと言う部分を含め、今回はApple, Google, MSといった巨大プラットフォーマーとFIDOの関係について整理します。

これまでのFIDOと巨大プラットフォーマーの関係

FIDOというとYubicoなどのセキュリティキーが印象的ではありますが、実際は端末自体を認証器として利用できる Platform Authenticator が特にコンシューマ分野においては重要だろうと言われてきました。Platform Authenticator側、つまりPC/Mobile端末のFIDO対応みたいなところで考えると、当然Apple/Google/MSの存在を感じずにはいられないですね。**

さらにWebアプリからFIDOを利用するためのWebAuthnについて、肝となるブラウザの対応においてもSafari=Apple, Chrome=Google, Edge=MSとあとはFirefoxなどが割と頑張って対応を進めたことである程度どこでも使える状況になったと言えますがこれはまぁいいか。

一方で、これまで数年にわたりパスワードレス認証やID連携についての動向を共有したりしてきた経験から、FIDOではユーザーが単独でサイトごとに強度の高い認証方式を利用できることで、認証器さえ持っていたらこれまで巨大プラットフォーマーとのID連携を利用してリスクベースなど含めた恩恵を受けてきたところから脱却できるのでは? という声も聞いたことがあります。OpenIDなんとかな立場でID連携いいですよ〜って推していると「認証の全てを巨大プラットフォーマーに握られるのもなぁ」みたいなことを言う人がいて、FIDOならそこから脱却できるのでは?と考えてた人がいました。言いたいこともわかります。

とはいえ、全体としては なんだかんだで巨大プラットフォーマーの対応に支えられてここまで普及が進んでいる と言える気がしていたところに、今回の発表によりそれがさらに加速するのではないかなーと考えています。

プラットフォーマーの力でどこまで便利になるのか?

上述の通り、FIDOにはセキュリティキーや対応端末そのもののロストなどのリカバリー、新規端末からの登録し直し面倒問題という課題もあるわけですが、今まではそれに対応しようとすると 複数の認証器でFIDOが使えるように設定しておく みたいなところしかなく、これも上に書きましたがデバイス自身が認証器として使える端末を複数台持っているようなユーザーでない限りC向けサービスのユーザーにとっては敷居が高そうだな遠いう状態でした。

それを、プラットフォーマーの力技でサポートしていこうというのが今回の話で、この記事が割と明るいです。

www.publickey1.jp

実は各社細かい違いがあったり、得意な部分みたいなのもあるのでざっくり整理すると次のような感じを目指そう!という段階です。

  • Apple / Google / MSアカウント毎にFIDOの秘密鍵(以下、パスキー)を管理できてログイン中の端末同士では セキュアな方法で 共有でき、バックアップもとれる
  • 初めて利用する端末では Bluetoothを利用して手元のスマホから利用可能

前者は少し前に Apple が発表したものそのものです。MSも同様な仕組みをやりたそうな発表をしていました。後者はGoogleAndroid端末で進めているものですね。

zenn.dev

MSは現状のAppleのようにアカウントベースに鍵の共有ができるようになりそうな雰囲気、AppleはいわゆるApple信者的な人であれば前者のみでもOKな感じなのであまり後者の仕組みはやってこない気もしなくはない、GoogleAndroidを用いて他社のプラットフォーム上での存在感を出したいと思っているように見えつつ、一度それをやったら鍵が共有されるような機能を乗せてくるのかなというところです。

blog.google

っていう細けぇ話はありますが、巨大プラットフォーマーの対応により、それぞれのアカウントベースでの鍵管理に近づいていくように見えますね。 今後の課題はプラットフォームを跨いだ鍵管理がどのように行われるかというあたりでしょう。Android -> iPhone に変更、その逆の場合にちゃんと鍵が共有されるような世界になるかどうか、各プラットフォームの利益目的だけでは進まなそうな後一歩を踏み出せるかが重要です。

ID連携 vs FIDO(改)

FIDOが鍵管理の部分でプラットフォーマー支えられる時代が来そうとなると、ID連携との違いがまた気になってきます。

  • ID連携ではサービスはID連携の仕組みだけが必要、とはいえOIDCの接続は必要。認証はIdPで行われもちろんIdPへの認証でFIDOを使うこともできる。
  • FIDO(改)はそれぞれのサービス毎に鍵管理が必要、プラットフォーマーがその鍵管理を支えてリカバリーや新規端末利用時のユーザーの負担を軽減

プラットフォーマーが前面に出るか後ろで支えるか、みたいな話になりそうですね。

認証機能単体の利用サービスの実装負荷としてはFIDO(改)の方がApple/Google/MSアカウントそれぞれとID連携するよりは軽いでしょう。 上述の通り、ユーザーがプラットフォームを跨ぐ挙動(Android -> iPhoneに変更)した時にちゃんとサポートできるかは、もう少し詳しく考える必要があるでしょう。

プラットフォーマー以外は今後どうなる?

Yubicoなどのセキュリティメーカーはどうすべきかってところは気になりますね。 個人的にはプラットフォーマーの鍵管理にうまく接続できる(セキュリティキーでログインしたら鍵情報が端末やプラットフォーマーのアカウントに共有される)方向になるのかなーと思ったりします。

終わり

最近のFIDOの動向を、巨大プラットフォーマーとの関係という観点から見ていきました。 個人の業務としても自サービスへのFIDOの導入を検討してはいるので、こういう動向を踏まえて使いやすい状態を目指していきたいところです。

ではまた!

GNAP超入門 ~ OAuth 2.0との違いとは

こんばんは、ritouです。

この記事はDigital Identity技術勉強会 #iddance のアドベントカレンダー 初日の記事です。 今年も張り切っていきましょう。

qiita.com

さて先日、Internet Week 2021なるもののために GNAP についてお話する機会がございました。

speakerdeck.com

45分間で各自が話す持ち時間は10分のためさわりだけしかお話しできませんでしたが、資料を見てもなんのことやらって感じだと思うのでここでもう一回説明してみます。

f:id:ritou:20211201131746j:plain

f:id:ritou:20211130105239j:plain

Grant Negotiation and Authorization Protocol 通称GNAP(読み方はなっぷとかぐなっぷとかじーなっぷとか、人によって呼び方がフリーダムなID界隈の謎しぐさ)ですが、OAuth 2.0のこれまでの経験と知識を踏まえて新しい権限移譲のプロトコルを作っていこうという取り組みです。

現在策定中の仕様はコアプロトコルとリソースサーバーの2つです。

f:id:ritou:20211130105304j:plain

  • コアプロトコル : 権限委譲を行うところまで
  • リソースサーバー : リソースサーバーが認可サーバーとどうやりとりしてリソースアクセスを提供できるか

これだけ見るとRFC6749の仕様を分解したように見えますが、実際のコアプロトコルの仕様にはいろんなことがいっぱい書いてあります(雑)

www.ietf.org

今回は現時点のGNAP概要とOAuth 2.0との違いにフォーカスしつつ、概要を紹介します。

f:id:ritou:20211130105313j:plain

最初のIntroductionのあたりです。

f:id:ritou:20211130105324j:plain

最初に何が書いてあるかというと、このプロトコルはいわゆるClientインスタンス(OAuth 2.0でいうところのClientですね)がAuthorization Serverに対してアクセス要求をどう行い、必要な対話を行い、目的とする情報へのアクセス権限をえるところにフォーカスしていますということです。また、インターオペラビリティについても言及があります。

f:id:ritou:20211130105335j:plain

GNAPにおけるRole、いわゆる登場人物を紹介します。ほとんどOAuth 2.0と同じ用語になっていますが、最後のEndUserっていうのがClientを操作する人物のことです。

OAuth 2.0のAuthorization Code Grantのあたりでは、暗黙的にこのEndUserとROが同一人物である想定になっています。 GNAPでは色々なユースケースを想定している中で、これが別の人物になる可能性も考慮しています。 既存のものだと、CIBAとかを想像してみてください。CIBAのConsumption Deviceを操作する人物についてはあまり意識しないかもしれませんが、必ずしも人間ではない場合もありますし、OIDCにおけるEndUserと一致する必要もありません。

f:id:ritou:20211130105344j:plain

GNAPがさまざまなユースケースで使われていくにあたり、Role間のTrustrelationshipが重要になります。 先ほど言ったようにクライアントを操作する人物とアクセスしたいリソースのオーナーが異なる場合はいわゆるUser ManagedAccess、通称ウーマと呼ばれる仕組みのユースケースに近くなるでしょう。業務システムの承認フローみたいなのにも適用できそうです。

その他にもRole間の関係性がプロトコルのどの部分に関連するかが言及されていますので、興味のある方は仕様を読んでみてください。

f:id:ritou:20211130114915j:plain

シーケンスの説明のところで、いくつかフローがあります。

  • Redirect-based Interaction : ブラウザのリダイレクトを利用してROとインタラクションを行う、OAuth 2.0のAuthorization Code Grantのようなフロー
  • User-code Interaction : ユーザーコードを利用する、OAuth 2.0のDevice Authorization Grantのようなフロー
  • Asynchronous Authorization : EndUserとROが別で、処理が分かれて行われるOIDC CIBAのようなフロー
  • Software-only Authorization : ROとの対話が存在しない、OAuth 2.0のClient Credentials Grant のようなフロー
  • Refreshing an Expired Access Token : 期限切れのアクセストークンを更新する、OAuth 2.0の Refresh Token を用いた Access Token 再取得のようなフロー
  • Requesting User Information : RSへのアクセスを要求せず、ROの情報を要求する、OIDCのようなフロー

OAuth 2.0では RFC6749 でいくつかのGrantTypeが定義され、Authorization Code Grantは認可エンドポイントへのリダイレクトによりROとのインタラクションが行われます。それ以外にROとのインタラクションを要求するDevice AuthZ Grant や OIDC CIBA などは新規のエンドポイントへのリクエスト/レスポンスが定義されたりします。ClientはASが提供するフローのうち、自分の使いたいものを選択して実装する必要があります。

GNAPのシーケンスでは、様々なユースケースに対応されている中で、最初にClientからASにアクセス要求を行う部分は共通になっています。 その時に、Clientは自分が対応しているインタラクションを提示します。ASはアクセス要求の内容を検証し、必要なインタラクションをClientに応答することでその後のROとのインタラクションに誘導します。 ブラウザのリダイレクトが行われるのか、デバイスフローのような遷移が行われるか、CIBAのようなpush経由の同意が行われるのか、ROとのrインタラクションなしで処理が続けられるのかが分岐していくわけです。

f:id:ritou:20211130114926j:plain

最後にOAuth 2.0との関係を紹介します。プロトコルレベルでの互換性はありませんが、先ほど紹介した通り、OAuth 2.0/OIDCで提案されているユースケースは想定されていますし、OAuth 2.0では解決できない、複雑になってしまうようなところも拾っていくような感じです。

仕様内でも付録にOAuth 2.0との違いが記載されております。Appendix B. Compared to OAuth 2.0" です。

f:id:ritou:20211130114937j:plain

ここでは6つの観点から整理されています。

  • Consent and authorization flexibility: OAuth 2.0(RFC6749)はブラウザでのインタラクションが定義されていますが、GNAPではDevice AuthZ GrantやOIDC CIBAのようなインタラクションまでサポートしています。
  • Intent registration and inline negotiation: これはシーケンスのところでも説明したように共通のアクセス要求から始まって、そこでネゴシエーションが行われるよってところです。
  • Client instances: OAuth 2.0において、ClientにはClientIDが割り当てられますが、GNAPはClientからASに提示された鍵の情報をうまく使います。
  • Expanded delegation: OAuth 2.0のscopeがresourceやRARという概念で拡張されていますが、GNAPは最初からRARのような柔軟な表現が使われています。
  • Cryptography-based security: OAuth 2.0ではClientSecretというBearer Secretがいろんなところで使われていますがFAPIなどでは別の方法が必要になります。GNAPではClientが保持する鍵を用いた暗号ベースの保護を利用します。
  • Privacy and usable security: OAuth 2.0はAS-RSの強力な紐付けが前提となっていますが、GNAPでは色々なパターンでAS/RSがやり取りできるように考えられています。

ざっとこんな違いが書かれています。

f:id:ritou:20211130114947j:plain

GNAPの最新情報はIETFのWG、ML、Githubを参照指定いただければと思います。

今回は超入門として、OAuth 2.0とGNAPの設計思想の違いを紹介しました。 この辺りを先に意識した上でGNAPのプロトコルの詳細を見ていくことで今までよりも読んでいくハードルを下げられるのかなと思ったりします。 今回な具体的なリクエスト/レスポンスには触れませんでしたが、続きの形でOAuth2.0と比べながら細かく見ていく記事も書こうと思っています。

また、まだまだ使われ続けるOAuth 2.0の各種フローをそのまま覚えるのでなくROとのインタラクション、トークン発行、クライアントとの紐付けやクライアント認証といった部分を細かいパーツに分けて理解し、GNAPはそれを組み替え直したようなものだと捉えられるようになったらもうこの辺の新しい仕様も怖くなくなります。これからも頑張りましょう。

明日のアドカレはAuthleteのあの人が記事を書いてくれそうです。楽しみですね! 私は今のところ、最終日に何かを書く予定です。 ではまた。

10/27に "iddance Lesson3 TwitterのOAuth 2.0とかCIBAの使い所を知ろうの会" やります

f:id:ritou:20211014102025p:plain

おはようございます、ritou です。 2週間ぐらい後に、こんな勉強会をやります。

idance.connpass.com

聞く対象としては初学者〜慣れてきたぐらいの人、話す方は使ってみた/本書いた/仕事で実装してみたぐらいの人を想定して開催してた勉強会ですが、オンラインでやるのどうなんかなーと考えつつしばらく間が空いてしまったのでまだ3回目ですが今回はオンラインでやります。

お話の内容は記載してあるとおりですが、静かに聞いて終わりってのよりは良くも悪くもガヤガヤしてる方が参加者/発表者のためになると思います。 もし今回の内容に関するこれが聞きたい、気になってるみたいな話や今後聞きたい話とかがあったらTwitterハッシュタグ #iddance つけてTweetしてもらうか、DiscordのServerに来てもらえたらと思います。

ぜひ参加してみてください。 ではまた!

OAuth 2.0等のRFC番号が飛び交う会話についていくためのカード [PR]

f:id:ritou:20211004023232j:plain

こんにちは、ritouです。

私は以前からこういうTweetをしていました。

このような日々の努力の結果、いわゆる「RFC番号が飛び交う会話」を身に付けたのです。

そして、このハードルを初学者が乗り越えていくために何ができるかを考えました。

その結果思いついたのが「ID-RFCカード」です。

r-weblife.booth.pm

何かというと、まず、RFC番号とタイトルの組み合わせをバーっと並べた「仕様カード」があります。

f:id:ritou:20211004023400j:plain

そして、RFC番号とざっくりな概要の組み合わせをバーっと並べた「解説カード」があります。

f:id:ritou:20211004023429j:plain

対象のRFCIETF

  • OAuth
  • JOSE
  • COSE
  • SCIM

のWGで仕様策定されたものと、WebFingerで合計41個です。

使い方も切って使うなりそのまま眺めるなり、無限にあります。

この「ID-RFCカード」で知識を蓄え、「RFC番号が飛び交う会話」に参加できるようになりませんか?

よろしくお願いします。

ではまた!