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

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

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

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

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

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

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

今回、 ※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等が有

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

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

error 必須
state 必須
error_description 任意
error_uri 任意

error
state

error_code
error_message

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

error
error_description
state

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

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

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