Zenn
🔒

OAuthについて勉強したのでまとめる

2023/01/01に公開
OAuth
tech

はじめに

認証認可まわりを業務で取り扱っていくことになったので自分の勉強ログとして記事にまとめてみます。

間違っているところがあればご指摘ください。

OAuthとは

OAuth 2.0 は, サードパーティーアプリケーションによるHTTPサービスへの限定的なアクセスを可能にする認可フレームワークである.
（中略）
OAuthは, 認可レイヤーをもうけてクライアントとリソースオーナーの役割を分けることで, これらの問題の解決に取り組む. OAuthでは, クライアントは, リソースオーナーのコントロール下にありリソースサーバーによってホストされているリソースへのアクセス権を要求する. そしてリソースオーナーのクレデンシャルそのものとは別のクレデンシャルを取得する.
保護されたリソースにアクセスする為にリソースオーナーのクレデンシャルを使う代わりに, クライアントはアクセストークンを取得する. アクセストークンとは, ある特定のスコープ, 期間およびその他のアクセス権に関する情報を示す文字列である. アクセストークンはリソースオーナーの同意をもって認可サーバーからサードパーティークライアントへ発行される. クライアントはアクセストークンを用いてリソースサーバーがホストしている保護されたリソースにアクセスする.
(RFC6749より引用)

つまり、サードパーティアプリケーションに対してリソース（多くはHTTPサービスとして提供される、たとえばGoogle Photoのようなサービス）への限定的なアクセス権を付与するための認可の仕組みと言えるかと思います。

リソースオーナーから同意をもって認可サーバーから受け渡されるアクセストークンを使うことで、クレデンシャルをサードパーティアプリケーションに引き渡す事なく、リソースサーバーへのアクセスを行うことができます。

OAuthの登場人物

  • リソースオーナー
    OAuthで認可する対象のリソースの所有者。リソースへのアクセスを許可する
  • リソースサーバー
    保護されたリソースをホストし、アクセストークンを用いたリクエストを受理してレスポンスする
  • クライアント
    認可サーバーからアクセストークンを取得し、リソースオーナーの代理として保護されたリソースに対するリクエストを行う。クライアントIDとクライアントシークレットをセキュアに保存できるクライアントをコンフィデンシャルクライアント、セキュアに保存できないクライアントをパブリッククライアントという
  • 認可サーバー
    リソースオーナーの認証と、リソースオーナーからの認可をもってアクセストークンをクライアントに発行する

OAuthの種類

  • 認可コードグラント
    認可コードと引き換えにアクセストークンを発行するグラントタイプ。４つのグラントタイプの中で最も重要。標準仕様では「コンフィデンシャルクライアントに最適化されたグラント」との記載があるが、PKCE(*)を使うことを前提にあらゆる種類のクライアントで推奨される
  • インプリシットグラント
    認可コードを発行せず直接アクセストークンを発行するグラントタイプ。パブリッククライアント向けのグラントタイプとの位置付けだったが、脆弱性があるため「認可コードグラント＋PKCE」を採用することが推奨されている。
  • リソースオーナーパスワードクレデンシャルグラント
    リソースオーナーのユーザー名とパスワードがクライアントを通して認可サーバーに送られるグラントタイプ。クライアントにパスワードが渡るため、クライアントとリソースサーバーの提供元が同じなど、リソースオーナーがリソースサーバーのユーザー名とパスワードをクライアントと共有しても良いケースなど限られた場合を除いて非推奨
  • クライアントクレデンシャルグラント
    クライアントと認可サーバー間のみのやりとりでアクセストークンを発行するグラントタイプ。クライアントがリソースオーナーを兼ねる場合に採用される

(*)PKCE…「Proof Key for Code Exchange」の略で「ピクシー」と読む。「認可コード横取り攻撃」の対策として、認可コードのリクエストをおこなったクライアントとトークンリクエストをおこなったクライアントが同一であることを確認する仕組み。詳細は割愛（また別の機会に書けたら書きます）

シーケンス図

一番重要な認可コードグラントのシーケンス図は以下の通りです。（以下の参考書籍に掲載されているものをdiagram.netで写経したものになります。著者の方が書かれた書籍のシリーズはとてもわかりやすいので気になる方はぜひポチってみてください）
雰囲気で使わずきちんと理解する！整理してOAuth2.0を使うためのチュートリアルガイド (技術の泉シリーズ（NextPublishing）)

上記の通り、クライアントにクレデンシャルを渡すことなく、クライアントは認可サーバーからアクセストークンを取得することができます。

また、上記の認可コードグラントの場合はアクセストークンがブラウザに渡らず、認可コードと引き換えに認可サーバーからクライアントに直接渡されるので流出の危険性が少ないと言えるかと思います。

インプリシットフローの場合は認可コードを介さずに認可サーバーからブラウザにアクセストークンが渡ることになるため脆弱性があります。

まとめ

OAuthは登場人物が多かったりフローが複雑だったり理解に時間がかかるが、シーケンス図を実際に書いて噛み砕きながら参考資料を読み進めると理解しやすいように思いました。

次回はOpenID Connectについてまとめたいと思います。

参考

The OAuth 2.0 Authorization Framework

雰囲気で使わずきちんと理解する！整理してOAuth2.0を使うためのチュートリアルガイド (技術の泉シリーズ（NextPublishing）)

Discussion