『雰囲気OAuth本』でOAuth完全に理解した

OAuthを理解して使いこなすために#

個人開発でFlutterでアプリを作るようになりました。これまでは、ユーザー認証などのないシンプルなアプリばかりでしたが、今度作りたいアプリではGoogleサインインなどを利用したユーザー認証必要になりそうでした。

ライブラリが用意されているので、実装は簡単にできそうだったのですが、裏側がどうなっているのかがわからなかったので、今回それを理解する第一歩としてこの本を読むことにしました。

雰囲気でOAuth2.0を使っているエンジニアがOAuth2.0を整理して、手を動かしながら学べる本[2023年改訂版]

表紙は異なりますが、内容の同じものがAmazonにもあるようです。

雰囲気で使わずきちんと理解する！整理してOAuth2.0を使うためのチュートリアルガイド

amazon

感想#

とにかくわかりやすかったです。
章の構成がしっかりしていて、一つ一つ知識を積み上げながら、理解を進めていくことができました。
途中でわからなくなっても、目次で理解できていないところがどこかすぐにわかります。

特に最も利用され、最も複雑である認可コードグラントについて紙面を割いており、シーケンス図で手順ごとに詳細な解説がされているのが良かったです。
各章の始まりでこれから説明することが説明され、関係するロールなどをしっかり紹介してくれていたのも良かったです。
OAuthほとんど初心者の私でもつまずくことなく、PKCEまで理解を進めることができました。
本当にいい本だと思います！

疑問解消#

フローを理解するのに非常に良い書籍だったのですが、読み終わった後にいくつか疑問点が浮かんできました。

1. リソースサーバーはどうやってトークンをチェックするのか#

OAuth本のフローでは、個の部分が取り扱われていなかったので、疑問が生まれました。
認可サーバーに問い合わせなくていいのか？問い合わせないでトークンが妥当であることをどう確認するのか？

RFC6749でもこの部分については詳しくは触れられていませんでした。
The OAuth 2.0 Authorization Framework

The resource server validates the access token, and if valid, serves the request.
p.8 [1.2. Protocol Flow]

The methods used by the resource server to validate the access token (as well as any error responses) are beyond the scope of this specification but generally involve an interaction or coordination between the resource server and the authorization server.
p.48 [7. Accessing Protected Resources]

基本的には、認可サーバーに問い合わせるのが一般的なようです。
他にもアクセストークン自体に情報をもたせる方法もあります。

このあたりの内容は、以下の記事で、識別子型、内包型として説明されています。
OAuth アクセストークンの実装に関する考察

2. リフレッシュトークンを使わずに、アクセストークンの期限を長期化させると何が問題か#

リフレッシュトークンを用いてアクセストークンを再生成できるのであれば、アクセストークンの期限を延ばしても問題ないのではと思いました。これには重要なリスクがあります。

まず、アクセストークンとリフレッシュトークンでは漏洩リスクに大きな差があります。
リフレッシュトークンは通常、クライアントと認可サーバー間の通信にのみ使用されるため、漏洩する機会が限られています。
一方、アクセストークンはクライアントとリソースサーバー間の通信にも使用され、より多くの場所で使用されるため、漏洩のリスクが高くなります。

アクセストークンの期限を長期に設定すると、以下の問題が生じます：

漏洩リスクの増大:
アクセストークンが長期間有効である場合、万が一漏洩した際に、そのトークンを不正利用できる期間が長くなります。これにより、攻撃者がトークンを利用してシステムへの不正アクセスを続けるリスクが高まります。加えて、漏洩した際の被害が長期にわたる可能性があります。
PKCEによる保護の限界:
PKCE（Proof Key for Code Exchange）は主に認可コードの漏洩を防ぐためのものです。アクセストークンがリソースサーバーとの通信中に漏洩する可能性を防ぐものではありません。ネットワーク盗聴、クライアントデバイスのセキュリティ欠陥、セッションハイジャック、ログやキャッシュの不適切な管理などによって(この場合、code_verifierすら漏れる場合がある気がします…)

定期的にリソースオーナーに確認させたくはない、けれど漏洩後の影響を考えるとアクセストークンの期限を長くはしたくない、そんな中で生まれたのがリフレッシュトークンなのでしょう。

単語整理(自分用)#

時たま見返して、OAuthの全体像が思い浮かべられるかに使うやつです。

OAuth(Open Authorization)
サードパーティアプリケーションにHTTPサービスへの限定的なアクセスを可能にする認可フレームワーク
- OAuth1.0
  - 署名を用いた認可方法
- OAuth2.0
  - アクセストークンを用いた認可方法
OAuth2.0に登場するロール
- リソースオーナー
- クライアント
- リソースサーバー
- 認可サーバー
OAuth2.0のトークン
- 認可コード
- アクセストークン
- リフレッシュトークン
OAuth2.0のグラントタイプ(フロー)
- 認可コードグラント
- インプリシットグラント
- クライアントクレデンシャルグラント
- PKCE(Proof Key for Code Exchange by OAuth Public Clients)
  - 認可コード横取り攻撃
OIDC(OpenID Connect)
- OAuth2.0を認証に利用できるように拡張したもの(OAuth2.0のまま認証に使おうとすると、脆弱性がある様子。)