RFC6749と並べて見る 様々な媒体の認可コードフロー

こんにちは。ATOM事業部の下江です。普段はフロントエンドエンジニアとして開発を行っています。

ATOMでは、様々な媒体(google, facebook, yahoo...等)とデータ連携をし、収集したデータはレポート出力するなどしてユーザに利用していただいています。 ほとんどの媒体ではデータ連携を行うために、OAuth2.0による認証・認可を行っています。

今回は媒体ごとの認証認可の仕組みの共通点や相違点について、認可コードフローについての記載があるRFC6749 と並べながら紹介していこうと思います。

(※これらは執筆時点 2021年10月 での情報をもとに作成しております。最新の状況については、各媒体公式ドキュメントをご参照ください。)

認可コードフローについて

RFC6749で定義されている認可コードフローの概要は以下となります。

f:id:so-technologies:20211025111335p:plain
認可フロー

今回、 ※1 認可リクエスト時 のリクエストパラメータ ※2 認可コードの発行&リダイレクトURLへリダイレクト のリクエスト/レスポンスパラメータについてご紹介します。

認可リクエスト時のパラメータ

認可リクエスト時、以下パラメータを付与してリクエストを飛ばします。

パラメータ名 RFC6749 google facebook yahoo
client_id 必須 必須 必須 必須
redirect_uri 任意 必須 必須 必須
response_type 必須 必須 任意 必須
scope 任意 必須 任意 任意
state 推奨 推奨 必須 任意
access_type - 推奨 - -

認可レスポンス時のパラメータ

認可コードの発行&リダイレクトURLへリダイレクト する際、各媒体から送られてくるレスポンス情報になります。 成功時、失敗時(承認しなかった、認可リクエスト時のパラメータ誤り等)でそれぞれまとめています。

成功ケース

パラメータ名 RFC6749 google facebook yahoo
code 必須
state 必須
その他 記載なし scope等が有

有: そのパラメータが返ってくることを示す

失敗ケース

媒体ごとに、パラメータ名が異なってます。

  • RFC6749
error 必須
state 必須
error_description 任意
error_uri 任意
  • google
error
state
  • facebook
error_code
error_message

※ 補記: ドキュメント上では、 error_reason error error_description が返却されるとの記載がありましたが、実際に叩いたときには上記パラメータが返ってきました。

  • yahoo
error
error_description
state

まとめ

各媒体ごとのOAuth認証の仕組みの違いについて、RFC6749 と共にまとめました。

どの媒体も RFC6749に準拠して作られている一方、必須となるパラメータが異なる等、媒体ごとに特徴がありました。

(※再度の補足になりますが、これらは執筆時点での情報をもとに作成しております。最新の状況については、各媒体公式ドキュメントをご参照ください。)