「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。

その文は正しいし、OAuthを正確に説明してるよ。デリゲートってただの標準的な言葉だから、辞書で調べてみて。内部の技術的定義はまさにその文の中にあるんだ。 >「何の前半か」 仕様書、標準の半分はXについて、もう半分はYについて扱ってる。つまり、一方はユーザーが第三者に許可を与える方法で、もう一方はその第三者がメインのデータ保持者にリクエストをする方法だよ。別の定義が必要なら、OAuthはユーザー、サービスプロバイダー、第三者の三者間プロトコルだよ。ユーザーは特定の権限を第三者に与えて、サービスプロバイダーがその第三者と特定のリソースを共有できるようにするんだ。

Googleのログイン確認方法10種類のリストが大好き。OAuthは最高だね。MFAは永遠に！

IETFは「企業のユースケース」に特化したコミュニティで、「シンプルなことができない」。彼は「今提供されているのは認可プロトコルの青写真であり、企業のやり方だ」と指摘し、「コンサルティングサービスや統合ソリューションを販売するための全く新しいフロンティアを提供している」と述べた。ロックダウン中に行われたインディーやフェディバースのカンファレンスでのOAuth 2.0に関するトークの終わりに、当時Oktaに勤めていたアーロン・パレッキが、実際にサービスを必要とするプロトコル/フローの部分を分離する価値があるのではないかと尋ねられた。つまり、あなたの「プロバイダー」が静的サイトをホスティングしている個人ドメインの場合でも、限られた認証やアイデンティティタグ付けができるようにするためだ。彼はすぐに、リモートカンファレンスだったから、仮想の部屋で最も愚かな人に話しかけているかのように振る舞い、そんな愚かな質問に対処することで肉体的な痛みを感じているかのように反応した。

一方、暗号技術のエンジニアリングの界隈では、「少なくとも変な暗号試みは全部取り除かれたから、今は同一オリジン/TLSのセキュリティだけだね」っていうのが一般的な感想だったと思う。

個人的には、oauthプロバイダーにアプリを登録する必要があるのはプラスだと思う。

OAuthのドキュメント自体を読んでるみたいだけど、なんか自分が理解できてないんじゃないかって思っちゃうような言い回しなんだよね。OAuthのドキュメント全体が、ぼーっと読んでるか、疲れてるときに目がさまよって、現実に戻るまで何も理解できない感じ。

ただの巨大なフレームワークになってるんだ、だってすべてを試みるから。そうだね、確かにそうなりがちだけど、必ずそうなるわけじゃない。必要なものによるし、もしマシン間認証みたいなものが必要で、クライアントを事前に設定できないなら、何か手を打たなきゃいけないし、他の人が知ってるものを使えばいいんじゃない？

ただの巨大なフレームワークになってるんだ、だってすべてを試みるから。私も仕事でOAuthを結構使ってるよ。SAMLも扱ったことがあるけど、週のどの日でもSAMLよりOAuthを選ぶね。単にOAuth（少なくともv2）が7年若いからだけじゃなくて、OAuthはその広がりがあるにもかかわらず、焦点を当てるべき部分を選べるし、時間とともに進化してきたから。全体のフレームワークはみんなのニーズに応えようとしてるけど、異なる仕様やRFCを通じてそれを実現してる。一方、SAMLは800ページの巨大な仕様で、時が止まってる。利用可能なツール（XMLとか）を使って、みんなのためにすべてになろうとしたけど、仕様は進化してないし（WGも閉鎖された）、決して消えないよ。多くの既存システムにとって解決策として埋め込まれすぎてるから。OAuthの代わりになるものが何かも分からない。GNAPを見たけど、OAuthに匹敵するものは見当たらないね。

ただの巨大なフレームワークになってるんだ、だってすべてを試みるから。そうだね、でも同時にそれは素晴らしいことでもある。すべてのことを扱ってくれるから。でも、全部使う必要はないんだ。私にとってOAuthのポイントは、認証層で起こる複雑な混乱があっても、最終的にはベアラートークンと多分リフレッシュトークンが得られることなんだ。自分でその認証の混乱を構築することもできるし、いくつかの異なるサードパーティプロバイダーを使ってそれをやってもらうこともできる。彼らはみんな同じベアラーとリフレッシュトークンをくれるから。そうすれば、認証を気にせずにアプリを構築できるんだ。すべてがそのOAuthのボックスの中で処理されるから。今、クライアント資格情報グラントからのリクエストを処理してるのか、認可コードグラントからのリクエストを処理してるのか？それがPKCEクライアントだったのか？クライアントの外では関係ないよ。