OAuthプロバイダーへの手紙

• OAuthプロバイダーへの手紙

  • GitHub

    • トークンエンドポイントが、エラー時にも200ステータスコードを返す
    • エラーレスポンスには400または401ステータスコードを使うべき

  • Facebook

    • トークンエンドポイントが独自のエラーレスポンスを返す
    • error フィールドを持つJSONオブジェクトであるべき

  • TikTok

    • サーバーが client_id の代わりに client_key パラメータを使用している
    • 仕様から外れている理由がない

  • Strava

    • サーバーがスコープパラメータにカンマ区切りのリストを使っている
    • 空白区切りのリストであるべき

  • Naver

    • サーバーがトークンの有効期限を文字列として返す
    • 仕様準拠かどうかを超えた問題である

  • さまざまなOAuthプロバイダー

    • クライアント認証のために、client_secret パラメータの代わりにHTTP Basic認証をサポートすべき
    • OAuth 2.1標準ではHTTP Basic認証は任意だが、PKCEが要求されるにもかかわらず、ほとんどのプロバイダーがこれを使っていない

  • AWS

    • OAuthクライアントライブラリと一緒に使った際に複数のバグ報告を受けたが、問題を再現できなかったため、関連内容を削除した

[rikko]

政府の対国民向けサービスプロジェクトを構築しながら、OAuth（OIDC）機能の実装だけで丸1か月かかった経験があります...

外部ライブラリを使えなかったため、一つひとつ全部実装しなければならなかったのですが、OAuth標準をきちんと守っていたのはカカオかグーグル以外にはありませんでした...

NAVERはまあ、ログインさえできれば問題ないというレベルで、これを使っていいのかと思うほどでしたし、Appleは今思い返してもどう実装したのか記憶にすら残っていないほど、既存のOAuthソースの3倍以上の実装コードが必要でした。

上の本文のようにレスポンスコードがめちゃくちゃな場合もあり、果ては418（I'm a teapot）を返すプロバイダーもありました。
こういう経験があるので、私はソーシャルログインのような機能は便利でも使わなくなってしまいました...

[GN⁺]

Hacker Newsの意見

• あるユーザーは会社のイントラネットでOAuthサーバーを実装した。他チームから公式仕様に従わないログイン実装を求められ、最終的に非公式なOAuthの亜種を作ることになった

• OAuthを使う際、複数のプロバイダーとメール登録の選択肢があると、以前どの方法でログインしたか思い出せず、誤って新しいアカウントを作成してしまうことがある

• 1年前に人気のAPI 100件についてOAuthを実装したが、経験はOPが説明したものと似ていた

• 多くのプロバイダーはprompt=select_accountをサポートしていないか、ユーザーにどのアカウントでログインするか選ばせない。これは特にOIDCで問題になる

• AWSに関するバグ報告を受け取ったが再現できず、該当セクションを投稿から削除した。ただし、一般的な問題点のチェックリストとしては有用だったかもしれない

• 公式のテストスイートがあれば、オープン標準の実装に役立つだろう。仕様を追跡するのは難しいため、検証できるテストスイートが有用なはずだ

• Facebookの問題は、既存のサービスフレームワークを使ってOAuth2を実装したものの、仕様に適合できなかったケースのように見える。スクリプティングにおける一般的な問題に似ている

• 一部のプロバイダーは仕様に従わず、リフレッシュトークン用に別個のエンドポイントを採用していた

• OIDC/OAuthプロバイダーに対し、SCIMをきちんとサポートし、「APIファースト」の考え方でシステムを設計するよう求めている。GNAPへ移行する前に、判断を再考する必要がある