セキュアなトークンへのJWT適用について

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

こういう記事を読みました。

lab.astamuse.co.jp

Webアプリケーションでセキュリティ対策のためにランダム文字列な文字列する場面が多々あります。例えば

• CSRF対策のトークン
• OAuthやOpenIDに使用するnonce, state
• メールの到達確認用URLのトークン
• パスワードをhashする際に使用するsalt

これらの値は単に衝突しなければOKというものではありません。十分なセキュリティ強度を確保するためには推測不可能なランダム値を使う必要があります。

私は持病を持っているため、ついつい「あー、これJWTなら...」と考えてしまいます。 今回は、こういうセキュアなトークンの方にJWTを使ったらどうなるかというお話をざっくり書きます。

ちなみに、乱数生成の話に異論を唱えるわけではありません。 今回の要件にある

• 衝突しない
• 推測不可能

ざっくり言ってしまえば前者はデータ設計、後者はセキュリティ面からの要件と言えるでしょう。

• 重複はしないんだけど生成される文字列の順番が決まってる文字列生成関数
• オートインクリメントな数値

とかを(プライマリー)キーにしてデータを管理しており、それを外部に露出して推測されて困るような場合、記事にあるような乱数文字列をふったりマッピングをもったりする必要が出てくるかもしれません。

そこで、JWTを使うとどうでしょうか？以前、似たような話を書きました。

ritou.hatenablog.com

この記事では "推測困難な文字列としてJWTが使えるんじゃないか？" という主張をしていますので興味ある方はどうぞ。 私の記事はいわゆるJWS(JSON Web Signature)を使うお話が多いのですが、キーの値をPayloadに含めることを考えます。

• JWTのPayloadはデコードしたら読める。ので、 データのキー自体は確認できるし推測できても良い場合 には使える。
  • ログイン中のデータ操作などはACLちゃんと確認しよう
• 署名がついているので、キーを変えて他人のリソースに...ってのは困難

という点から、

記事にあるような乱数文字列をふったりマッピングをもったりする必要が出てくるかもしれません。

これをしなくても実用に耐えうるものとなるでしょう。

もちろん、良いことばかりとは言いません。

• 鍵の管理が必要 : パスワードの処理とかには向かないかもしれません
• 署名生成/検証処理が必要 : たくさんの処理をするものであれば無視できない部分でしょう

という話は出てきます。 それでもJWTを適用するメリットを享受するために、"文字列自体にメタデータを保持できる" 点を挙げておきます。

例えばセキュアなトークンにこんなメタデータを追加していったらどうなるでしょう。

1. 単純な文字列 "だけ" をキーにしている場合 : "1234567890qwerty"
2. 用途を含む "prefix" などがついている場合 : "sid_1234567890qwerty"
3. 生成日時、有効期限などがついている場合 : "sid_1234567890qwerty_1628974596"

こういう値を追加することによって、データストアを参照する "前" にある程度弾くなどの処理ができそうです。 いろんな用途でセキュアなトークンを利用したい場合、キーとなる値 + 様々なメタデータを含むことで無駄なデータストアの参照を減らしたり、別の用途に文字列を利用も検知、拒否できます。

JWTの場合、署名により改竄されていないことを検証できるので、あとは

• Header : 用途をこのレベルで分けてしまい、署名検証前にチェックする
• Payload : 発行日時や有効期限などを持ち、データアクセス前にチェックする

と言った部分を工夫することで、必要最低限のデータアクセスを追求できるのではないでしょうか。

いかがでしたでしょうか？

JWTは "データを保持する際のキーとなる乱数文字列" をメタデータとともに保持することで、キーの種類に関わらず改竄不可能な値として扱えて無駄を省いたハンドリングが可能なので、セキュアなトークンとして利用するのに便利な仕組みじゃないですか？ というお話でした。

JWT「我々はなんたらランダムで生成した乱数をキーとしたデータと共存できるし、なんならオートインクリメントの値でも工夫すれば問題を起こさずに実現できる。文字列自体にメタデータを持つという発想に辿り着いたら呼んでくれ。」

— 👹秋田の猫🐱 (@ritou) 2021年8月14日

ではまた。

Chrome 93で実装されたCross Device WebOTPフローを試してみた

おはようございます ritou です。 8月ですよ。お仕事の進捗大丈夫ですか？ 最近、Google方面からDecoupled AuthNの香りがしたので追ってみました。

何の話?

この話です。

developer.chrome.com

WebOTPとは?

Webアプリケーションがモバイル端末でSMS経由のOTP認証をしようと思った時、画面に「認証コードを送信しました」なんて出た後にSMSを確認できるアプリを起動して確認してまたブラウザに...とかをやったことがある人は多いでしょう。 WebOTPとは、モバイル端末上のブラウザであればアプリの切り替えをせずにワンタップでSMSで受け取ったOTPの値を読み込んで検証リクエストに繋げられる、しかもSMSを発信したWebアプリを特定できるフォーマットになっていることでフィッシングサイトからはこのフローを使えなくするような仕組みのことです。

web.dev

Cross Device WebOTPとは?

Desktop(PC) ブラウザとモバイルブラウザで同じユーザーでログインしていたら、Desktop側のブラウザでWebOTPのシームレスなフローを実現できる仕組みのことです。

細かい話は以下のドキュメントに書いてあります。

docs.google.com

どんな動きをするかと言うと、

1. ユーザーがPCのChromeでSMS検証フローを開始
2. WebアプリはWebOTPに対応したOTP入力フォームを表示しつつSMS送信
3. SMSを受け取ったAndroid端末で動いているChromeがOTPを取得、ユーザーの許可を得た上でPCのブラウザに送信
4. PCのChromeでOTPが自動入力されて処理を継続

と言う流れで、"手元のAndroidでOTPを受け取ってPCに送り、PCブラウザでSMS検証が完了できる" のが特徴です。

試した

デモのやり方が書いてあります。

準備

• PCブラウザとしてChrome 93以降を用意する(私はChrome betaを用意しました。)
• Google Play Service のバージョンが 20.30.12 より上のAndroid端末を用意し、こちらもChrome betaを入れる
• Android端末の設定でChrome betaを規定のブラウザに設定する
• どちらの環境でもGmailなどを開き、同一ユーザーでログインする
• 念のため再起動する(ある人から聞いたおまじない)

デモサイトの使い方

デモページを開きます。

web-otp-demo.glitch.me

Send following SMS message to this phone from another one after pressing "Verify".

とあって

Your OTP is: 123456.

@web-otp-demo.glitch.me #123456

と書いてあるので、"Verify" を押したらターゲットとなるAndroid端末に向けて別の端末からSMSを送ったり、Twilioの無料枠を使ったりしてSMSを送信します。

あとは入力フォームのまま、PCブラウザでは待ってれば良いです。 AndroidにSMSが届くと、PCブラウザにOTPを送っても良いか？と聞く通知が来るので「送信」を押すと、PCブラウザの画面でOTPが入力されたようになって検証成功します。

成功したときのPC側の画面を録画したものを含むTweetを載せておきます。

できたできた！

1. PCのChrome BetaでOTPフロー開始
2. Androidに通知がきて送信って押す
3. PCのChromeにOTPが送られて成功！

バージョン低めのAndroidでも普通に動いた！ pic.twitter.com/hHDLdEwEgO

— 👹秋田の猫🐱 (@ritou) 2021年7月31日

Androidへの通知はこんな感じ。 pic.twitter.com/1Xz9U1iJV7

— 👹秋田の猫🐱 (@ritou) 2021年7月31日

いかがでしたか？ 今までのOTPの認証フローがChromeのサポートにより Decoupled AuthN へと進化してしまっています。

何がすごいのか

個人的には

• 互換性を保ちながら便利に使える人が増えること
• OTPの認証フローを使っているサービスであれば誰でも使えること(そう、Googleユーザーならね)

と言う2点で、Googleさんすごいなって思います。

前者について、新しい認証フローみたいなのを考える場合「対応していない環境」をどうするかが課題になります。 WebAuthnの場合は関数の利用可否をもとに「導線を出さない」みたいな実装がされたりするでしょう。 それに対して今回のはこれまでのOTPのフローを拡張したものです。環境によって

• SMSを受け取れる端末上のブラウザならば : OTP取得をスムーズに実現可能
• PCブラウザでもSMSを受け取れるAndroid端末で同一のGoogleユーザーでログインしていたら : OTPを送信してスムーズに利用可能
• どちらでもなかったら普通のOTPフロー

と言うように、WebOTPに対応しているだけでWebアプリ開発者が意識しないところで "勝手に" 便利にできるわけです。 これは良いですね。(ユーザーサポートと言う点ではパターンが複雑になる面倒さもあるかもしれません。)

後者については、これがGoogleにログインするため"だけ"のものではないということです。 WebOTPを導入している全てのサービスがこの恩恵を受けられる可能性があります。 ちょっと前にAppleがWebAuthnを拡張して便利にするぞ〜みたいな話を書きましたが、広い意味では似たような感じですね。

ritou.hatenablog.com

今後もプラットフォームやブラウザによる便利な実装が話題になったらチェックしてみたいと思います。 ではまた！

(動かね〜ってTweetしたら色々とサポートしていただいた えーじさん、ありがとうございました！)

フィッシング被害が多発しているというAmazonからのセキュリティ通知の仕様の危うさ

こんにちは、ritouです。

こんな記事を見かけました。

internet.watch.impress.co.jp

Amazonをかたるフィッシングが報告全体の35.8％を占め、特にSMSによるものが多かった。同協議会では、SMSではメールよりも本物と誤解したり、ついアクセスしたりしやすいため、注意が必要だとしている。

Amazonでなんでもポチれる時代にこれは切ない事態です。 今回はその Amazonから送られてくるセキュリティ関連の通知の仕様がよろしくないのでなんとかして欲しいというお話 をちょっとだけします。

セキュリティ通知

中の人じゃないので細かい仕様を全て把握できているわけではありませんが、例えばログインの設定をいじろうとしたときなどにこんな画面が表示されます。

SMSとメールで通知を送ったので確認しろという内容です。

その下の謎の申請ってのはもしかしたらアプリへの通知かもしれませんが、昔いろいろあって今はアプリを入れてないのでSMSとメールを見てみます。

そして送られてきた内容を見てみましょう。

左がSMSです。

• 送信元の検証が困難すぎぃ
• URLを送ってくるUXが存在することでフィッシングにかかりやすくなる
• URLつけたら届かないとかいう都市伝説も昔からある気がする

と言った観点からもSMSでリンクを送るのはよろしくないでしょう。

こんなことやってるから "Amazonをかたるフィッシングが報告全体の35.8％を占め、特にSMSによるものが多かった。" なんて言われてしまうのです。

右のメールの方も、

このEメールがAmazonから送信されていることを確認するにはどうすればよいですか? このEメールのリンクは「https://www.amazon.co.jp」で始まります。以下のリンクをいつでもブラウザに貼り付けて表示できます。

とか書いてあってなんとなく厳しい感じが伝わってきます。

URLの検証が困難なので個人的には避けたいところですがメールでURL送信は長い長い歴史があるので難しいところですね。

提案するなら

• リンクは送るな
• 何かを送ってそれを入力させる、2FAでよくあるフローの方がまだ良さそう
• メールで怪しくないアピールするならURLにアクセスして表示された後もドメイン確認しろって言え

あたりでしょうか。

今度、アプリの方も見てみます。

おまけ

メールのタイトル。

何を言ってるんだ、amazon.co.jpはお前だろ。

ではまた。

FIDOアライアンスのUXガイドラインには何が書いてあるか

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

前の投稿でも取り上げたWebAuthnとかFIDO認証って呼ばれてる認証方式のお話です。

ritou.hatenablog.com

今回は、FIDOアライアンスからUXのガイドラインが出ているので紹介します。

fidoalliance.org

• FIDO UX Guidelines - FIDO Alliance
• UX GUIDELINE PDF - FIDO Alliance

一言で言うと

MacとかiOSとかAndroidとかWindowsの生体認証が使えるデバイス上でWebアプリを使ってるユーザーに対して、新規登録/ログインフローのなかでをどうやってデバイスを登録させてFIDO認証を使わせるか

っていうお話です。

今回のターゲットとしては一般的なユーザーが使いつつ、強固なセキュリティが求められる銀行のWebアプリケーションのようなところを想定しています。FIDOにより一番平和になって欲しい世界のお話です。

これまでtoCのサービスでも、FIDO認証を取り入れる際には「YubiKeyのようなセキュリティキーを用意させるよりも "デバイス自体" を登録してWindows/Mac OS/iOS/Androidそれぞれで提供されている生体認証をする方が使われるようになるだろう」というのは以前から言われていました。

しかし、実際にどのようにデバイスの登録を求めるかと言ったあたりは先行して導入するサービスがそれぞれ探り探りやっているような部分があったので、このUXガイドラインによりその辺りの迷いが解消されることに期待せざるを得ません。

構成

UXガイドラインは3つのコンセプトとして User journey, Process steps, Use Case の3つがあります。

1. User journey : エンドユーザーがFIDOのAuthenticatorを登録し、そしてログインするまでの処理が対象です
2. Process steps: “sign in(ログイン)” とか “detect device eligibility(デバイスの適合性の検出)” みたいな細かい処理をまとめて “awareness” とか “consideration” と言ういくつかのゴールを表現し、目的を達成するためにこうしたら良い！ってのが整理されています
3. Use Case: 銀行のWebアプリを想定してます
4. Biometric sign-in or FIDO sign-in: 生体認証もしくはデバイスアンロック手段を用いたFIDO認証を利用することを想定しています

(3つと言いつつ4つ書いてあるじゃないか)

ゴールとProcess Stepsの関係はこんな感じで図示されています。

• Awareness : このサービスはFIDO認証に対応してるよと伝える
• Consideration : ログイン中のユーザーをAuthenticatorの登録に誘導する
• Registration : Authenticator を登録する
• Sign-out (post registration) : Authenticatorを登録してからそれでログインしたりログアウトしたり

と言う感じですが、まずは細けぇことはあまり気にせず画面ごとの要件を拾っていければ十分でしょう。

テストサイト

このUXガイドラインの参照実装として、テストサイトが用意されています。

https://digitalbank-test.com/

• メールアドレスや電話番号などは不要
• ユーザー名、パスワードで登録
• 登録したユーザー情報は30日で消滅

となっているので気軽にお試しいただけます。が、どうせみんな見ないでしょう。 IDの技術なんてそんなもんです。「後で読む」「後で見る」IDおじさんは知っています。なので動画をとりました。

これは「iPadでもちゃんと動いた！(けどAuthenticator登録完了時に必ずエラー出るな！)」って言う動画です。

www.youtube.com

ガイドラインにもこのサイトのスクリーンショットが掲載されています。 この後の説明でも実際に動作させた自分用のスクリーンショットを載せていきます。 では見ていきましょう。

UXガイドラインの内容紹介

Awareness: Sign in Pre-FIDO Registration

目的 : 自サービスでFIDO認証が可能であることを複数の方法で宣伝する

最初に、FIDO認証をサポートするデバイスを利用するユーザーに対して、永続的/一時的なメッセージングによりRelyingParty(FIDO認証を利用するサービス)がFIDOに対する認知度を高めることが説明されています。ユーザー調査によると、登録(Authenticator登録の意味かも?の)前に何度もFIDOの概念について触れる必要がありそうとのこと。

まず、未ログイン状態のログインフォームを見てみましょう。

ここにはFIDOと言う文字は出て来ません。プラットフォーム毎の生体認証っぽい画像を表示することでこのサービスは生体認証に対応してるんだな〜ってのを認識させようと言うのが狙いです。(私の環境はChrome on Mac OSなのでTouchIDっぽい指紋認証のアイコンが表示され、マウスオーバーで説明が出て来ます。Android や Windows 環境の時はそれぞれのプラットフォームの中で使われている生体認証の画像を使うという細かい出しわけが紹介されています。)

この後に出て来ますが、うちのサービスはFIDO認証に対応してるんだ！ではなく、生体認証に対応してるんだよってアピっていくと言うのがポイントですね。

Because the FIDO brand is not yet familiar to most consumers...

謙虚！

他にも

• セキュリティ設定変更機能からいつでもAuthenticatorを登録/削除できるようにする
• eメールのチャンペーンやメール配信、ソーシャルメディアで生体認証が可能であることを通知する
• CSに教育する

みたいな涙ぐましい努力をしながら、FIDO認証を促進していかなければなりません。

Consideration: Targeted invitations

目的 : FIDO認証をサポートするデバイスにログイン中のユーザーを、Authenticatorの登録画面へと案内する

Chrome on Mac OS や Safari on iPad OSなどでテストサイトに登録して再度パスワードを用いてログインし、ログイン状態になったら、画面に案内用のメッセージが表示されます。

ここでの"FIDO認証をサポートするデバイス" ってのはいわゆる Platform Authenticator の利用が可能なブラウザのことであり、WebAuthnの仕様でいうところの "isUserVerifyingPlatformAuthenticatorAvailable()メソッド"を使って判断をしているように見えます。

なので、例えば同じPCでも生体認証が動かないブラウザの場合はこれは表示されません。

あと、ガイドラインにはもう一つ "Spotlight" page takeover invitation format for Mac users ってのが載ってます。 どっかの広告のように全面に主張してくる感じなんだと思いますが、どこで出るんやこれは...

その他、

• パスワード認証に代わる安全な認証方式だという価値を示す
• 案内のメッセージは "シンプル(シンプルな認証方式を利用できるよ)" もしくは "オプショナル(安全な認証方式を追加できるよ)" が効果的
• 対象デバイスの場合は何回も案内しよう！けど設定は必須にせず、ユーザーの制御可能にしておく(ウザがられたらダメ。要はバランス...)
• Authenticator登録ページにたくさんリンクさせる

などが記載されています。

Registration

目的 : 対応デバイスを利用しているユーザーにFIDOについての教育を行い、Authenticatorを登録させる

先ほどのトースト通知から "Register now" に進んでいくと、Authenticator 登録のための説明画面に遷移します。

• この設定は必須ではないので右上の "×" から取り消すこともできる。ユーザーが制御可能なように
• アニメーション画像で生体認証の流れを説明
• 既にコンピュータのアンロックに使っている方法でアカウントにログインできることを説明
• "Learn more" を押すとFIDOの説明が展開
• FIDO CERTIFIEDなロゴ表示

ここぞとばかりにFIDOの説明してますが、これぐらいしないとユーザーは何だか分からなくて使わないってことなんでしょう。 ちなみにFIDOのロゴ利用についてはこの辺りを確認しましょう。

Logo Usage & Style Guide

Organizations that wish to use the FIDO logo on websites must adhere to the terms of our FIDO Trademark and Service Mark Usage Agreement for Websites license. You can download our logo files here.

Authenticate

目的 : Windows HelloやApple Touch IDでログインできるようにAuthenticatorを登録する

いわゆるAuthenticatorの登録処理です。 WebAuthnの仕様でいうところの "navigator.credentials.create()" を呼び出すところですね。

先ほどの画面から "REGISTER" を選ぶと処理が始まります。

成功すると画像も成功っぽくなってます。

失敗の場合もそれっぽく変わります。Platformごとの生体認証の画像に続いてこの辺りは芸が細かいなーと思ってしまいますが、現代のUXとしてはそれぐらいやらんといけないってことなのでしょうね。

ちなみにテストサイトでは Authenticator登録直後に100%の確率でIBMのなんたらエラー画面が出てウワッてなりますが、一旦心を落ち着けてトップのURLにアクセスしなおせば何事もなかったかのように続けられます。。

FIDO Sign-in

目的 : 登録済みのデバイス上でユーザーをFIDO認証する

最後に登録済みのAuthenticatorを用いてログインさせる部分です。 WebAuthnの仕様でいうところの "navigator.credentials.get()" を呼び出すところですね。

テストサイトでは、ログアウトした後に

• ユーザー名
• "SIGN IN" ここからWebAuthnのログインが始まる
• FIDO CERTIFIEDロゴ
• ユーザー変更リンク : 空のパスワード認証フォームへ
• パスワード認証への切り替え : ユーザー名が保管されたパスワード認証フォームへ

といった構成の画面になります。

これなら一回でログイン処理が走りますが、ここで注目なのは"ログアウト" してもユーザー名が保存されているということでしょう。

我々はつい "ログアウト" というと完全にセッションデータを吹き飛ばし、フォームに何もない状態からのやり直しを想像してしまいますが、そこからこの処理を行う場合は一度ユーザーを特定する必要があります。

この辺りは

• 最後にログインしていたユーザーのユーザー名を記憶しておく
• そのユーザーがFIDO認証を利用可能な状況(環境+デバイス)ならばログイン画面からすぐに開始できるようにしておく

というあたりを意識していく必要があるのかなと思います。 昔から "最後にログインした方法" "最後にログインしたユーザー" を記憶しておくみたいなアイディアはあるので、この辺りはもう少し整理しようと思います。

ちなみに後から気づきましたが、このテストサイトは Console Log に処理途中のデータもいくつか流しているのでWebAuthnの具体的な実装を見たいときにも参考にできそうです。

(ログアウト状態でも最後に利用したユーザー名が保存されているあたり)

(WebAuthnのログインが行われる時もログが吐かれるあたり)

それ以外にも、Authenticatorの管理もできるようになっているので、この辺も参考にできそう。

と言ったあたりで一連の流れに沿ってガイドラインの内容を紹介しました。

感想

今回のガイドラインには

アカウント登録 -> Authenticator登録 -> ログアウト -> FIDO認証でログイン

の流れに沿ってどのようなUXにしたら良いかというのが書かれています。 また、FIDOアライアンスからはいわゆる "アカウントリカバリー" のために複数のAuthenticatorを登録させるためのホワイトペーパーも出されていたりするので、今回のと組み合わせて参考にしながら実装してユーザーに提供する必要がありそうです。

すでにいくつかのサービスでFIDO認証は使われ始めていますが、開発者向けのサービスより一般的なユーザーに向けての啓蒙となるとより詳しい説明が必要になるでしょう。

ちなみに、個人的にこの前ちょっとハマったのが

1. SMS番号やメアドを入力
2. ユーザーの登録状態によって分岐
   1. Authenticator登録済みユーザーならWebAuthnの認証フロー開始
   2. Authenticator未登録ユーザーならSMS認証

みたいな処理をレガシーなフォーム送信を使って実装しようとしたら、iOS/iPad OSのSafariでうまく動かないと言う挙動にハマり苦戦しました。 理由はちょいと細かい話で、Safariはユーザーの明示的なアクションが起こらないとWebAuthnの処理が行われないようになっており、"ユーザーのクリック"をトリガーにする場合は問題ないものの、"ユーザーのSubmitボタンによるレガシーなWebアプリのフォーム送信"ではWebAuthnのフローが開始できないみたいな癖があります。Chromeでは問題なし)

今後作るときは、今回のUXガイドラインを参考にしたいと思います。

ではまた。

Appleの発表したPasskeys in iCloud KeychainはWebAuthnをどう変えるのか

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

先日のWWDC2021の "Move beyond passwords" というセッションにて発表された "Passkeys in iCloud Keychain" という仕組みについてどんなものかを紹介します。

developer.apple.com

WebAuthn

数年前からパスワード認証を置き換えると言われ続けている認証技術の一つである "WebAuthn" (やFIDO)という技術をご存知でしょうか。(ご存知ない方は "WebAuthn builderscon" "WebAuthn droidkaigi" などで検索してみましょう) 今回の話をするにあたって、WebAuthnがどんなものかをある程度理解しておく必要があります。

• 公開鍵暗号の仕組みを利用
  • パスワード認証のようにユーザーとログイン対象のWebアプリケーションがパスワードを共有するのではなく、PC/スマートフォンの端末や外付けのセキュリティキーの中に秘密鍵、を保存しつつ生成した署名を送信、ログイン対象のWebアプリケーションが保存している公開鍵を用いて検証する
• ローカル認証を利用
  • スマートフォンのロック解除に使われるような指紋、顔認証、パターン、4桁PINなど でユーザーを確認する
• 認証フローにWebブラウザが介入して一連の認証処理が行われたOrigin情報をWebアプリケーション側が検証可能なため、フィッシングのリスクを排除できる
  • 2段階認証でよく使われているワンタイムパスワード入力はフィッシング対策にはならない

ということが特徴です。

WebAuthnでは秘密鍵が保存されているデバイスを所持していること、ローカル認証により意図したユーザーが操作していることを検証できるので、単体でもWebアプリケーションのログイン機能の要件を満たせる、かつフィッシング耐性もあるので素晴らしいものだ、という主張です。

この機能が普及するためのキモとして

• デバイスの対応("秘密鍵"の保存)
• ブラウザの対応(WebAuthnプロトコルへの対応)

があります。

前者については、YubiKey(Yubico)やTitan(Google)というようないわゆる "SecurityKey"だったり、スマートフォン/PC自体がその機能を持ちます。 後者についてもPC/スマートフォン向けの対応ブラウザが増えており、今後ますますコンシューマ/エンタープライズ両方での利用が増えていくであろうという状態だとここしばらく言い続けています。

しかし、このWebAuthnの悩ましい問題として、”リカバリー困難問題” があります。

• デバイスに保存された秘密鍵は他の端末にシェア/コピーできない

という仕組みのために、デバイスが紛失、壊れてしまったら当然、そのデバイス内に保存されている秘密鍵を用いた認証が利用できなくなってしまいます。

• スマホもセキュリティキーも、壊れたり壊されたり落としたり無くしたりとにかく平和じゃない(経験済み)
• PC/スマートフォン自体に秘密鍵を保存するケースでは、新しい端末で使い始める時に手間がかかる
  • 一度 "別の方法" でログイン状態にしてから、"このデバイスでWebAuthnを利用する"(鍵ペアの生成、公開鍵のやりとり) という一連のフローをやりなおさないといけない
• この "別の方法" で安全なものがなくて困る
  • WebAuthnが最強！なので他の認証方式だと認証強度が弱くなってしまうんじゃ
  • ベストなのは 認証に利用できる状態になったセキュリティキーを大事に引き出しの中にしまっておく ことだけど、コンシューマ向けのユーザーにそこまでさせるのは正直きつい

というのが長年議論されてきました。

Appleの動画にある比較表の"Security Key"の項目で、"Always with you" はユーザーがいくらWebAuthn使いたくても秘密鍵が保持されているデバイスがないとダメよってこと、"Recoverable" はデバイスロスト時に困るってことが表現されています。

Passkeys in iCloud keychain

散々前フリしたところで、Passkeys in iCloud keychainは、ここまで話したWebAuthnの困ってるところをうまく解決しようという試みです。

概要

一言で言ってみると、WebAuthnのキモである デバイスに保存された秘密鍵は他の端末にシェア/コピーできない という部分を デバイスに保存された秘密鍵を「安全な方法」で他の端末とシェア/同期できる ようにすることで、デバイスロスト/リカバリーの問題を解決しようとしています。

Appleの場合は、iCloud Keychainを用いることで他のApple端末とWebAuthnで利用する秘密鍵を共有するぞってわけです。

iCloud キーチェーンを使えば、パスワードやその他の機密情報をお使いのすべてのデバイスで最新の状態に同期できます。

support.apple.com

用語的には、"Passkeys" = "WebAuthnの秘密鍵を共有可能な仕組み" それを iCloud Keychainから利用するんだというのが "Passkeys in iCloud Keychain" だというところでしょう。いや、テキトーなことは言わんほうが良い。

WebAuthnとの利用フローの違い

例えば、WebAuthnに対応したWebサービスAと手元に🍎なデバイスが2台ぐらい(iPhone/iPad)があるとしましょう。

1. iPhoneでは指紋認証を設定済み
2. WebサービスAにiPhoneでログインし、新たなログイン方法としてiPhoneを設定
3. WebサービスAをiPhoneから利用する際は指紋認証でOK
4. iPadでは顔認証を設定済み
5. WebサービスAにiPadから何らかの方法でログインし、新たなログイン方法としてiPadを設定
6. WebサービスAをiPadから利用する際は顔認証でOK

となっていたところが、

1. iPhoneでは指紋認証を設定済み
2. WebサービスAにiPhoneでログインし、新たなログイン方法としてiPhoneを設定
3. WebサービスAをiPhoneから利用する際は指紋認証でOK
4. iPadでは顔認証を設定済み、iCloud Keychain で秘密鍵を同期!!!
5. WebサービスAをiPadから利用する際は顔認証でOK

となります。

セキュリティキー(を持ち歩いてUSBの形があれやこれや言いつつとりあえず使えたわ！っていうの)と同じ体験がAppleデバイスを持っててiCloud Keychainで同期してるってだけで味わえます。 このリストだけではあんまり便利になった感覚がないですが、これが複数のWebサービス×複数の端末ってなっていくとじわじわ違いとして現れてくるでしょう。

使い物になるかどうか、懸念点はないか

WebAuthnのデバイスロスト/リカバリーの問題を避けられるとなればWebAuthnの普及促進に繋がるでしょう。

秘密鍵の管理という点では、Passkeys in KeyChainはこれまで "デバイス単位" でセキュリティを担保していたものが、プラットフォームを支える "Identity単位" のセキュリティで担保することになります。 秘密鍵にアクセスできる端末が増えたということは、それだけ不正利用のリスクも増えると考えることもできます。 WebAuthnをログインに採用しているサービスから観ると、これまで設定済みの端末のみに絞られていたリスクが、iCloud Keychainで同期している全てのApple端末全体に広がってしまうことを認識する必要があるでしょう。

このメリット/デメリットを意識するまでもないコンシューマ向けサービスにとっては良いニュースだと思いますが、NIST SP800-63シリーズ で定義されている、厳密なユーザー認証の強度(Authenticator Assurance Level, AAL)を厳密に意識する必要のあるレベルのサービスには多少気になるかもしれません。 "他の端末にシェア可能な秘密鍵は利用できない" "Passkeys in Cloud KeyChain経由のアサーションは受け入れない" みたいな細けぇ分岐処理が出てきたらカオスになるので避けたいところです。

ID連携との違い

Appleはこれを独自の技術としてアッピールするというよりは、「他のPlatform(と言ってもGoogle/Microsoftを名指ししているようなものですが)でも同じような仕組みを用意して使って行ったらいいじゃない」みたいなスタンスを取ろうとしているのが新鮮なところですが、結局大きなPlatformを持つ巨人たちのための仕組みじゃねーか と感じる人もいるでしょう。

デバイスからIdentityへみたいなことを言ったついでに、Sign in with Appleのようないわゆる "ID連携" と今回の "Passkeys in Keychain" の仕組みの比較をしてみたいと思います。

• Webアプリ側はWebAuthnのプロトコルを意識するだけで、しれっとAppleアカウントのセキュリティの恩恵を受けられるのが "Passkeys in Keychain"
  • 開発者はWebAuthnに対応するだけ
  • ユーザーは個々のWebアプリごとに一度手元のApple端末でログインの設定が必要
• Webアプリ側が明示的にAppleアカウントの恩恵を受けにいけるのが "Sign in with Apple"
  • 開発者はSign in with Appleの実装が必要
  • ユーザーはAppleドメイン上で認証するだけ

Sign in with Appleでも顔認証などを使ってパスワードなしで認証できることから、"WebAuthnによるログインやID連携の設定済みの状態でApple端末からのUX" という点では同等になり得そうですが、開発者、ユーザーと言った視点では細かい違いがあることを意識しておきましょう。

この辺りの比較は、実際に動きを見れる状態になってから比較してみるのが良さそうですね。 できるようになったらやります。

まとめ

• WebAuthnはセキュリティキーや対応デバイス単位で秘密鍵を保管する仕組みだったが、デバイスロストやリカバリーなどに課題があるってずっと言ってる
• Passkeys in iCloud KeyChainはiCloud KeyChainの同期の方法を用いて、秘密鍵を安全に共有するための仕組みである
• デバイスからIdentityレイヤーにコンテキストが変わることで、ID連携に近い感覚になるが、こまかいところで違いがある

というお話でした。何はともあれ、普及が楽しみですね。 質問があったらマシュマロかTwitterでいつでもどうぞ〜。

marshmallow-qa.com

ではまた！

【久々の投稿と思ったら】Web24というイベントで 5/8 12:50~14:20にお話します【告知】

お久しぶりです、ritou です。

今週の金/土に行われるこんなイベントにお誘いいただいて、5/8 12:50~14:20にWebアプリケーションとIDについてセッションオーナーとして議論させてもらうことになりました。ハッシュタグは #web24_id です。

connpass.com

どんな展開になるのかのネタばれではなく、最近の私の思いを少し書いておきます。

一言で"WebアプリケーションとID" と言っても、

• いわゆる認証方式
• 登録から退会までのライフサイクル
• ID連携

など多岐にわたっています。

さらに、Webアプリケーション単体で見た時も

1. Webサーバーからの応答だけ
2. Webサーバー + SPAのようなクライアントの組み合わせ...
3. Webブラウザが提供するAPIを利用...

という具合に考慮すべき範囲が複雑化しており、IETFやW3Cでは新しいプロトコルやAPIが続々と策定されていく... 開発者が個別の機能の要件をしっかりと理解して作り込んでいくよりも、フレームワーク、IDaaSなどを用いて安全性を担保しながらアプリケーションを作り込んでいく時代にあると言えるでしょう。 当然、サービスとしてモバイルアプリケーションが存在する場合はさらに考慮すべき点も増えそうです。

そんな時代に開発者はどのようにIDと向き合っていくべきか、というのをお話できたら良いのかなーと思っており、個人的に標準化仕様、ライブラリやプロダクト開発辺りを意識できる3人の方 にお声がけをさせていただきました。 特に打ち合わせも台本もなくやっていくのでどんな展開になるかは想像もつきませんが、なんとか盛り上がったら良いなと思います。 お時間のある方は見に(聞きに)来て下さい♪他のセッションも豪華メンバーで楽しみですね！

ではまた！

最近よく見かける初心者エンジニアが転職の際に作る今時のポートフォリオに必須だと噂の「ゲストログイン」について

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

タイトル長くてすみません。

QiitaでID連携や認証まわりの投稿記事を見ていると、最近「ゲストログイン」という文字列が目に止まることが増えたので何か書いておきます。

ゲストログインとは

「ゲストログイン」の検索結果 - Qiita

実はそんなに引っかかりませんが、このゲストログインと呼ばれる機能、実装者により内容もバラバラです。 どれが正解ってのもない気はしますが、1/31ぐらいの検索結果からどんな認識なのかを見てみます。

qiita.com

ポートフォリオ必須といわれているゲストログイン。

そうなの？

それとは異なり今回のゲストログインはあらかじめ設定されたデータでUserを新しく作成します。 なので「ゲストログイン」より「簡単新規作成」の方が言葉的に近いかもしれません。

  def guest
    user          = User.new(user_params)
    user.name     = "ゲストユーザー"
    user.email    = SecureRandom.alphanumeric(15) + "@email.com"
    user.password = SecureRandom.alphanumeric(10)
    user.save
    sign_in user
    redirect_to how_to_path
  end

ランダムデータで新規登録&ログインさせる系っぽい。

qiita.com

ポートフォリオを作成する際はゲストログイン機能が必須と言われています。

やっぱり、そうなんだ？

Google認証やTwitter認証を頑張って導入しても、自分のアカウントを使うことが心理的なハードルになって、アプリを良く見てもらえない可能性が出てしまいます。

ソーシャルログインに心理的ハードル...ｻﾞﾜｻﾞﾜ

const user = { name: 'ゲストユーザー', email: 'guest@example.com' };

予め用意してたユーザーでセッション生成っぽい。

qiita.com

今回はポートフォリオを見てもらう確率を上げるために必須な、簡単ログインの実装方法を書いていきます。

また必須言うてる。これあれじゃないの？スクールでそう言われた系じゃないの？

  # emailでユーザーが見つからなければ作ってくれるという便利なメソッド
  user = User.find_or_create_by(email: 'guest@example.com') do |user|
  # 自分はユーザー登録時にニックネームを必須にしているのでこの記述が必要
  user.nickname = "ゲスト"
  # 英数字混合を必須にしているので、ランダムパスワードに、英字と数字を追加してバリデーションに引っかからないようにしています。
  user.password = SecureRandom.alphanumeric(10) + [*'a'..'z'].sample(1).join + [*'0'..'9'].sample(1).join
  end

ニックネーム、メアド固定のゲストさんで(最初は登録しつつ)ログイン状態に。パスワードはなんとなく設定する。

qiita.com

新規登録で mail: guest@guest, password: 111111で登録していること

この人でログインさせる。

qiita.com

たくさん読まれてるやつ。自分もコメントしてみたけどもなんだかもうカオス。 上記の予め用意していたアカウント系のリスクが書いてある。

qiita.com

転職活動用のポートフォリオ等にゲストログイン機能があると、多忙な採用担当の方の負担が減り、アプリを利用してもらえる確率が高まるメリットがあります。

利用した気にさせることが大事っぽい！

ゲストログイン用のユーザー(ゲストユーザー)の登録されている

予め用意されている系

※セキュリティをしっかり固める場合、ゲストユーザーのアカウントを通常のユーザーアカウントと一緒に、usersテーブル/Userモデルで管理するのはあまり望ましくありません。

これはわからん。一緒でもいいだろ。

最後に、セキュリティ的な対策です。 もしあなたの開発しているアプリに、ユーザー名やメールアドレス等を編集できる 「ユーザープロフィール編集機能」がある場合、 ゲストユーザー用アカウントのものに関しては変更できないようにした方が良いと思います。

ゲストユーザーを扱うためにアプリにも分岐入れて判断とかが必要。

と言うところで、どうやら

• ポートフォリオにゲストログインは必須
• とは言え定義はなんかふんわりしてる
• **予め用意したユーザーでログインさせる系が多い

ってぐらいな感じです。

本当にこの程度の機能でアピールになるのかは採用側の経験者の意見も聞きたいところですが、 控えめに言うと フレームワークが標準で提供していない機能を追加するだけでも価値はあるでしょうし、想定外のことが起きてそれに対応することも経験としては重要な気はします。

みたいなことをTwitterで言ってたら質問来てました。

あります。

要件などを一般化したものをいつかzennに書きますね。#マシュマロを投げ合おうhttps://t.co/jesOMA0ysq pic.twitter.com/CTsP5zefy9

— 👹秋田の猫🐱 (@ritou) 2021年1月7日

せっかくなのでこれぐらいまで実装したら実用的かも？ってのを書きます。

実用的なゲストログインとは

そもそも「ゲストログイン」と言うか「ゲストユーザー」機能ってのの実用的、汎用的な要件はどうなんでしょう。

• ECサイトで会員登録をせずに商品を購入するゲスト購入
• ゲーム系のサービスで会員登録をせずにある程度まで使えるお試しプレイ

あたりを考えてみると、

• メアド確認やパスワード設定など、新規登録をせずともある程度もしくはフルでサービスが利用できる
• 他の端末、セッションからは同じユーザーでログインできない/紐づけられたデータを流用できない
• サービスが気に入ったら改めて新規登録を行い、データは引継ぎつつ全てのサービスを利用できたりできなかったり

みたいなところが要件として出てくるのではないかと考えます。 それを設計/実装に落とそうと思うと

• Userモデル
• セッション管理
• アクセスコントロール
• 本登録処理とデータ引き継ぎ

あたりになります。それぞれのポイントを整理してみましょう。

Userモデル

まぁ、こんなのは一例でしかないわけでありますが、Userモデルに対する要件としては

• ゲストユーザーであることを判定できる
• メアドなどを識別子とする場合は空
• パスワードなどのクレデンシャルが空
• ニックネームなどプロフィールは登録可能

ぐらいでしょう。

小規模なアプリにありがちなUserモデルであれもこれも含むてんこ盛りモデルだったりすると "必須" 項目になっているものがあり、なかなか対応が困難になる場合もあるかもしれませんが、あまりランダムな値などを入れるのは望ましくないでしょう。

上記の記事でメアドやパスワードにランダムな値をいれるような実装もみられましたが、実際のプロダクトで "設定することでログイン可能になる" 場合は "知らないからいいだろう" と言う話でもないでしょう。

これは極端な例ですが、規模が大きくなることを想定したアプリなどで細かくテーブルを分けるようにするなら、

• 識別子を払い出す : User(ID発行は既存のものと一緒で良い)
• 識別子とロール : UserRole としてゲスト状態を保持
• 識別子とメアドを紐付ける : UserEmail を持たない
• 識別子と認証方式、クレデンシャルを紐づける : UserCredential を持たない
• 識別子とプロフィール情報 : UserProfile は持つ

みたいな管理をすることで、ゲストユーザーの要件に対応できそうです。

ゲストユーザー用のモデルを用意する方法もあり得るとは思いますが、この後言及するアクセスコントロールの部分やデータ引き継ぎなどを実装する際に既存のアプリの機能に大きな改修が入らないように気をつける必要があります。

セッション管理

ECのゲスト購入であれば、購入フローで必要な値を引回す必要があります。 これは未ログイン状態のセッションに紐づけることでも実装できますが、この後言及するアクセスコントロールをしっかり実装できるならば、ゲストユーザーによる処理を開始する際に

• ゲストユーザーを作成
• セッションとの紐付け

を行うことで実現できそうです。

アクセスコントロール

ビジネス向けに比べて比率は少ないかもしれませんが、コンシューマ向けのサービスでもユーザーのロールを意識してサービスの利用制限を行う例はあるでしょう。 例えばゲームなどでいわゆるユーザーランクによって利用できる機能が解放されると言うことはそれに近いかもしれません。ゲストユーザーを扱う際も同様です。 上記の記事でも触れられていたものもありましたが 「ゲストユーザーが利用できない機能」を決めておき、利用制限をしっかり行うこと も重要でしょう。

本登録処理とデータ引き継ぎ

ゲームなどのゲストログインでは

• ゲストユーザーの利用が制限された機能を利用しようとした
• 利用可能なゲームのポイントを失った

と言うあたりで本登録処理を促し、そのまま設定などを引継いで利用できるような実装が必要となりそうです。 ECサイトでは購入フローが完了した後などに会員登録を促して継続的な利用を促したりもするかもしれません。

Userモデルのところで意識したゲストユーザーと通常のユーザーの違いを意識して、既に設定してあるプロフィール情報や同一セッションでユーザーが入力した情報は生かしつつ不足している部分を埋める実装が必要となるでしょう。

まとめ

• 最近目に付くゲストログインについて調べた
• ここまでやれば実用的かな？ってとこを説明した
• スクールかなんか知らんけど、ゲストログインを課題にするならもうちょい詳しく教えろ

転職を考えている初心者エンジニアの皆さんの成功と、より一層のご活躍をお祈り申し上げます。

以上です。

おまけ画像

ではまた！

噂のマイナンバー要求APIをCIBA+FIDOで作れないか考えてみた

こんばんは、ritouです。

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

qiita.com

何の話か?

このプレスリリース、ニュースを覚えていますでしょうか。

www.jiji.com

マイナンバー要求APIの説明としては

事業者が同APIを導入すると、利用者にマイナンバー提出をリクエストすることが可能となります。それを受けた利用者は、PINコードを入力、もしくは生体認証（指紋または顔認証）した後、マイナンバーカードのQRコードをスマホで読み取り、そしてカード本体をNFCで読み取るだけで瞬時にマイナンバーを提出することができます。

とあります。これはこれで "瞬時にマイナンバーを提出"とはどの部分にかかってるのかが気になる文章ではありますが、xIDのサイトにも説明があります。

my-number.x-id.me

今日はこのマイナンバー要求APIの仕組みを標準化仕様、既存の技術を組み合わせて作るとしたらどんな感じかと言うところを考えてみます。

マイナンバー要求APIのフローを理解する

上述のサービスに概要が書かれております。

(引用元 : https://my-number.x-id.me/)

xIDアプリでやることっていうのがこの図ですね。

(引用元 : https://www.jiji.com/jc/article?k=000000023.000037505&g=prt)

これを5つの処理に分解しましょう。

1. サービスからのマイナンバーリクエスト : 属性情報要求
2. ユーザーへの通知、確認コード選択 : ユーザーへの通知
3. PIN or 生体認証 : ユーザー認証
4. マイナンバー入力 or QR読み通り + マイナンバーカード読み取り : マイナンバー取り扱いのためのお約束
5. 暗号化して送信 : 属性情報応答

で、それぞれの処理に標準化仕様をあてはめてみましょう。

1. 社内のマイナンバー登録フローみたいなのに入り、サービスはこのユーザーのマイナンバーが欲しいとxIDに要求、ユーザーには確認コードを表示 : →CIBA
2. xIDはアプリへの通知を用いて「サービスがマイナンバーを欲しがってるよ」と通知、ユーザーは表示された確認コードと一致するものを選択 : →CIBA
3. 通知を受けたxIDアプリでPINもしくは生体認証を行うことで2FA完了 : →FIDO
4. マイナンバーを入力もしくはQR読み取りを行い、さらにマイナンバーカードをNFCで読み取る : →マイナンバー取り扱いのお約束
5. xIDアプリで暗号化されたマイナンバーがサービスに返される : →CIBA(w/ JWE?)

1,2,3について、「手元のスマホでログイン」的な流れ、利便性を上げるためにFIDOとの組み合わせ、なんてところは本ブログで何度も扱ってきた通りです。 4の処理については「民間事業者におけるマイナンバーカードの活用」というPDFなどに記載されている券面事項入力補助APを使う際のアクセスコントロールに従っているようです。

https://www.cao.go.jp/bangouseido/pdf/topic_card_minkan.pdf

これの券面事項入力補助APの②で、アクセスコントロールで求められるマイナンバーがその前に入力/QR読み取りってとこか(と教えてもらった) pic.twitter.com/YezVamp34L

— 👹秋田の猫🐱 (@ritou) 2020年12月9日

あとは5のところでモバイルアプリの段階で暗号化して送ってサーバーも見れませんよ！って言えるなら出来上がりでしょう。

CIBA/FIDO で作るマイナンバー要求API

ここまで分解できれば、あとはシーケンス書いてそれぞれの処理を整理しましょう。

登場人物

実際はxIDのアプリの他にxIDのバックエンドサーバーがいるだろうと言うところで、登場人物は4人と言うところでしょうか。

• RP : マイナンバーを要求するサービス
• IdP(Backend) : マイナンバー要求API(xIDのサーバー)
• IdP(MobileApp) : xIDアプリ
• EndUser : マイナンバーカードを保持するユーザー

シーケンス

シーケンスはこんな感じでいけそうです。

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

RPからIdPにマイナンバー要求、受付応答

CIBAにおける、バックチャネル認証リクエストに相当します。

• RPは社員番号、メールアドレスなどを login_hint などとして指定
• 確認コードは binding_message として指定

CIBAにはPOLL/PING/PUSHと言ったモードがありますが、ここではPOLLモードを想定し、auth_req_id が返されます。

確認番号の選択

これは以前、手元のスマホでログインみたいなのをCIBAで実現しよう！みたいな記事でも触れた気がしますが、EndUserがこのフローの正しい利用者であることを確認する仕組みとして binding_message をうまく使うことで実現できそうです。 この、3つ表示して1つ選ばせるみたいな部分は結構普通に使いそうなので、CIBAの仕様として組み込んでも良さそうな気はしています。

PIN or 生体認証

xIDアプリは所持 + αの2要素認証をうたっています。 それに相当する仕組みとして、ここでは FIDO を用いることで実現できそうです。

マイナンバーカードのお約束

ここは標準化仕様というよりもガイドライン的なものに従って作る感じですね。

暗号化したマイナンバーのやりとり

この辺りはモバイルアプリでJWE形式にしたIDTokenを生成、もしくはマイナンバーだけを暗号化するなどよしなにしてバックエンドサーバーが復号できない状態とし、RPまで返してやる、そして破棄することで実現できそうです。

まとめ

• マイナンバー要求APIの仕組みを分解してみた
• CIBA/FIDOとかを組み合わせたら作れそうだったのでシーケンスなどを考えてみた

いかがでしたでしょうか。 ある程度、認証認可周りのプロトコルの理解が進んだ状態であれば、何か新しい仕組みが出てきたときにこんな感じかなーと考えて見ることもできるでしょう。 まぁ実際に実装するとなると細かくいろんなこと決めないといけないんでしょうけど、頭の体操をしてみても面白いのではないでしょうか。

何か気になることがありましたら、匿名でも質問受け付けておりますので気軽にどうぞ！

marshmallow-qa.com

私のアドカレ次回作は12/25の予定です。

qiita.com

で、その間に会社のやつを20日にQiitaの方に書く予定です。

qiita.com

ではまた！

参考

qiita.com

ritou.hatenablog.com

ritou.hatenablog.com

ritou.hatenablog.com

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

おはようございます。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における状態と状態遷移を表現したものです。

5つの状態

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

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

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

状態遷移

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

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

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

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

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

パスワード認証

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

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

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

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

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

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

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

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

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

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

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

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

ソーシャルログイン

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

と言うお話でした。

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

marshmallow-qa.com

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

qiita.com

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

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

こんばんは。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の登場人物から振り返ってみましょう。

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

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

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

OAuthの特徴としては

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

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

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

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

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

何がいけないのか？

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

ID連携の最低限の要件

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(これ以外に 「モバイルアプリ」はただのリダイレクタとなり「バックエンドサーバー」がアクセストークンを取得し、プロフィール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トークンを用いることで安全に実装できます。

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

モバイルアプリ+バックエンドサーバーなクライアントでは、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