「Twitterでログイン」っていうのが新しい革命的なアイデアだった頃に、OAuthログインを作ったことを思い出すよ。その頃は、詳細を扱うためのライブラリなんてなかったから、TwitterやFacebookのエンジニアが書いたブログを元に直接作ってたんだ。あの頃はまだ標準化もされてなかったと思う。あの辛い経験のおかげで、今はOAuthが本当にシンプルに感じるようになった。V2でかなり整理されたしね。

私にとって、MicrosoftのOAuth 2.0に関するページを読むのがすごく助けになったよ。イラスト付きのフローチャートがあって、それからRFCに戻るといい感じ。とはいえ、非自明な詳細がたくさんあって、特に多くの場合、OAuth 2.0を基にしたOIDCを扱わなきゃいけないから、急にJWKやら何やらに直面することになるんだよね。

OAuthについて、謙虚に言うと、もっと良いアナロジーを借りたいんだけど、ダグラス・クロックフォードからのもので、彼が関数型プログラミングのモナドについてコメントした内容をアレンジすると、こんな感じになる。「OAuthはシンプルなアイデアだけど、呪いがある：理解すると、説明する能力を失う。」

実装が正しいかどうかをチェックするためのバリデーションやテストスイートって、どこかにありますか？

たくさんの人が苦労する理由は、消費者の視点からOAuthを始めるからだと思う。つまり、彼らはデータをリクエストする第三者で、OAuthの実装はリソース保持者によって強制されるから、明確な理由がない多くの手続きを踏まなきゃいけない。サービスプロバイダーやリソース保持者の視点からOAuthを始めると、全てがクリアになるよ。ウェブセキュリティもそんな感じで、CORSやHTTPSのような問題に直面する人は、セキュリティの問題を解決しようとしているわけじゃなくて、上流のプロバイダーがユーザーのデータを信頼されるためにセキュリティ基準を上げるように強制されているからなんだ。

自宅のラボでOIDC（Autheliaを使って）を使ってるけど、すごく簡単に扱えるよ。何をやってるのかよく分からないけど、ドキュメントを信じてるし、特に難しい設定ってわけでもないんだ。

AはBにアカウントを持ってて、Cにも別のアカウントがある。AはCにBのデータにアクセスさせたい（またはAの代わりにBにデータを送信させたい）。BはCがAの代わりに行動しているとどうやって確信できるの？Aはリスクを減らすためにCに特定のデータだけにアクセスを許可することはできるの？その三者間の交渉を可能にするプロトコルがOAuthなんだ。ほとんどの仕様書と同じように、複雑さは後の年に、何千人ものユーザーや複雑なエッジケースを持つ企業によって追加されていくんだ。彼らが議会を支配していて、彼らのニーズが新しいバージョンを推進してる。だから、ほとんどの仕様を学ぶ最良の方法は、古い仕様から新しいものに学ぶことだよ。OAuth2を最初に読んだり使ったりすると、余計な複雑さに圧倒されるから、現役の専門家もそんな風には始めてないよ。追いつきたいなら、いつも古い仕様やバージョンから始めるのがいいよ。

OAuthをクライアントとサーバーの両方で実装したことがあるけど、一番複雑なのは散らばったドキュメントや、異なるプロバイダーからのちょっとしたトラブルだね。全体としては、そんなに複雑じゃないんだ。

いや、それはSAMLのことを考えてるよ。

完全に同意だね。OAuth、Auth0、Okta、OIDC。