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）を返すプロバイダーもありました。
こういう経験があるので、私はソーシャルログインのような機能は便利でも使わなくなってしまいました...