🔐

OAuth2.0の流れをまとめてみる

5 min read

※この記事は別アカウント(hyiromori)から引っ越しました

はじめに

最近、個人的に認証認可周りを学習していて、その過程でOAuth2.0について学習している内容をまとめた記事です。

世の中には既にOAuth2.0に関する優れた書籍やブログ記事が沢山ありますが、自分が学習する過程で色々なものを読むことでより理解が深まったと思うので、自分も学習したものをアウトプットすることで同じように学習している人の理解の助けになればと思い書きました。

まだ私も学習中なので、もし間違ったところなどあればコメント頂けるとありがたいです。

注意点

この記事内ではOAuth2.0で定義されているフロー の1つ、認可コードによる付与(Authorization Code Grant)についてまとめています。
たくさんの仕様をいきなり網羅的にまとめるのは難しいので、1つに絞って今回はまとめています。

OAuth2.0に定義されているフローの解説については、こちらの記事が参考になりました。

https://qiita.com/TakahikoKawasaki/items/200951e5b5929f840a1f

OAuth2.0とは何か?

OAuth2.0は認可を行うためのプロトコルで、所有者の代わりにリソースへのアクセスを許可するためのプロトコルです。

もう少し具体的な例を出すと、エンドユーザーがあるサービスに対して別のサービスへのアクセスを許可するためのトークンを発行するための手段といった感じです。
(OAuth2.0は様々なケースに対応できるので、もちろん上記の具体的な例以外のシーンでも使用できます)

認証と認可

OAuthは認可のためのプロトコルですが、認証を行うためのプロトコルではありません
ここを間違えると、セキュリティ上の大きなリスクが発生する場合があります。

認証と認可の違いについては以下の記事が参考になりました。

https://dev.classmethod.jp/articles/authentication-and-authorization/

また単なるOAuth2.0を認証に使ってしまうと、どういったセキュリティ上のリスクがあるのかは以下の記事が参考になりました。

https://www.sakimura.org/2012/02/1487/

OpenID Connect

OpenID Connect は OAuth2.0 の拡張規格で、認証を行うこともできるようになっています。
(この辺りは別の記事でまとめる予定)

まとめました。

https://zenn.dev/hyiromori/articles/2021-01-30-oidc

OAuth2.0の登場人物

OAuth2.0では複数の登場人物(サーバー)が連携して認可を行います。

リソースサーバー

resource server

保護対象のリソースを保持しているサーバーを指します。
保護対象のリソースは様々なものがあり一概にこれとは言えませんが、例えばGoogleフォトの画像や、SNSの投稿などをイメージすると分かりやすいかもしれません。

リソースオーナー

resource owner

保護対象のリソースを所有している人を指します。
OAuth2.0を使ってアカウントを連携をしたいエンドユーザーとも言えると思います。

クライアント

client

保護対象のリソースにアクセスするソフトウェアのことを指します。
こちらも対象は様々なので一概にこれとは言えませんが、Web開発者であればWebアプリと考えておくと理解しやすいかもしれません。
画像もWebブラウザをイメージしたものにしていますが、Webアプリ以外のクライアントも存在します。

認可サーバー

auth server

リソースサーバーに信頼されたサーバーで、リソースオーナーの認証を行い、リソースサーバーに対するアクセストークンを発行できます。
OAuth2.0において重要な役割を果たすサーバーです。

OAuth2.0の流れ

認可コードによる付与(Authorization Code Grant)の流れをまとめます。
自分が学習している時に「もうちょっと具体的な例を使った説明がほしいな〜」と思っていたので、私が実際に試してみた以下の構成をベースに説明します。

  • 認可サーバーはGoogle
  • クライアントはWebアプリ

また以下の点に注意してください。

  • 理解しやすくするために、パラメーターなどは必須の項目のみに絞っています(例えばセキュリティ上推奨される state やPKCE関連のパラメーターなどはあえて省いています)
  • HTTPの例は、OAuth2.0に関係する部分のみに抜粋しています。

1.認可サーバーへのリダイレクト

Redirect to authorization Server

Googleと連携したい時に、クライアントから必要なパラメーターを付与して、Googleの認可サーバーへのリダイレクトさせます。

リダイレクトで行う理由は、クライアントを識別したりする情報を付与してGoogleの認可サーバーにアクセスさせるためです。

HTTPの例

クライアント(Webアプリ)内のリンクなどをクリックすると、リダイレクト専用のエンドポイント(例: /request_authorize)にアクセスします。

GET /request_authorize HTTP/1.1
Host: https://client.example.com

このエンドポイントからは必要な情報をクエリパラメーターにセットされたURLが返却されて、Googleの認可サーバーへリダイレクトします。

HTTP/1.1 302 Found
Location: https://accounts.google.com/o/oauth2/v2/auth?client_id=(CLIENT_ID)&redirect_uri=https%3A%2F%2client.example.com%2Fcallback&scope=email&response_type=code

パラメーターの解説

リダイレクト用のURLに付与されているクエリパラメーターを解説します。

client_id

OAuthの設定をした際に発行されるクライアントIDです。
どのクライアントが認可を要求しているかを識別するために使用されます。

redirect_url

リソースオーナーが連携を許可した後にリダイレクトされるURLです。
自由にリダイレクトURLが設定できてしまうと、悪意あるサイトに認可の情報が漏れてしまうため、事前に設定されたURLと一致させる必要があります。

scope

何に対するアクセスの認可を要求するかを表しています。

2.認可サーバーでの確認

Authenticate on authorization server

リソースオーナーに対して、要求されている認可を許可してよいかどうかを確認されます。
リソースオーナーは必要に応じてパスワードなどで認証を行い、要求されているスコープを確認して、問題なければ許可します。

Googleでの例 ⬇
Google authentication example

3.認可コードの発行

Issue authorization code

許可されると、アクセストークンを発行するための認可コードを発行して、クライアントへリダイレクトします。
先に説明したとおり認可コードが外部にもれないよう、リダイレクトは事前に設定されたURLのみ可能です。(大事なことなので2回書きました)

HTTPの例

以下のように認可コードをクエリパラメーターに設定された状態でリダイレクトします。

HTTP/1.1 302 Found
Location: https://client.example.com/callback?code=(認可コード)

クライアント(Webアプリ)で定義されたエンドポイント(例: /callback)に認可コードが渡されます。

GET /callback?code=(認可コード) HTTP/1.1
Host: https://client.example.com

4.アクセストークンの発行

Issue access token by authorization server

リダイレクト時に付与された認可コードを認可サーバーに渡して、アクセストークンを取得します。

5.リソースサーバーへアクセス

Get resources with access token to resource server

取得したアクセストークンを使って、保護されたリソースにアクセスします。

まとめ

なるべくOAuth2.0の概要が分かりやすいように、最低限のものに絞って書いてみました。
実際に使うには情報が不足していると思いますが、OAuth2.0の理解の助けになれば幸いです。

参考資料

学習する過程で参考になった資料をまとめておきます。

書籍

ブログなど