OAuth 2.0/OIDCに入門した開発者が仕様沼に潜るための次のステップとは？

f:id:ritou:20200430112204p:plain

お疲れ様です、ritou です。

OAuth 2.0やOIDCの入門書(?)を読み終えた開発者の方に、仕様を理解していくための次のステップは何があるかを聞かれました。

そもそもそんなこと言う人は

クライアントを実装したい(しなければならない)
認可サーバーを実装したい(しなければならない)
セキュリティエンジニアを名乗っていてこの分野を抑えときたい
ただ単純に興味がある : そんな人いる？

とかそんな感じな気はしますが、基本的なフローを乗り越えた先に広がる仕様沼への潜り方に戸惑っておられるようでした。そこで、いわゆる RFC6749/6750/7636 あたりを完全に理解した開発者が山ほどある仕様にどう立ち向かっていくかを考えます。

仕様にも色々ある

IETF の OAuth関連の仕様、いっぱいあります。密です。密です。みみみみみみみみ...

tools.ietf.org

去年に一回まとめ記事を書きました。

qiita.com

OIDCの方もあります。

openid.net

こっちはまだまとめ記事完成してません(やる気が404 not found)

とりあえず、仕様にはいくつかの種類があります。

既存のフローの一部を拡張
新たな認証認可フロー
ベストカレントプラクティス(BCP)

などで分類できますが、まずは自分が求めている仕様はどの辺りかを見極める必要があるでしょう。

コンシューマ向けのサービスであれば Device Flow などの新たな認可フローに手を出すのも良いでしょう。脅威、脆弱性とその対策を知りたければBCP系を攻めるのもありでしょう。この2つのやり方はそんなに迷わずに取り組めるかと思いますが、FAPIなどを見据えて既存の認可フローを強化するような拡張仕様を見ていく場合はどこから攻めていくかよく考える必要があるでしょう。

認可フローの分割と対応する仕様の見極め

例えば認可コードフローの拡張仕様を見ていく際、一旦フローを分割して考える方法をお薦めします。

認可(認証)リクエスト
認可(認証)レスポンス
アクセストークンリクエスト/レスポンス
リソースアクセス
トークンイントロスペクションリクエスト/レスポンス

そして仕様がこれらのどこに対応するものかを整理します。どれか一つにだけ対応しているわけではなく、複数のパートに関連している場合がほとんどです。最近Activeな仕様でいうと...

JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
- アクセストークンリクエスト/レスポンス
- リソースアクセス
- (Implicitだったら認可レスポンス)
OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer(DPoP)
- アクセストークンリクエスト/レスポンス
- リソースアクセス
OAuth 2.0 Pushed Authorization Requests
- 認可リクエスト
- (新規エンドポイント)
OAuth 2.0 Rich Authorization Requests
- 認可リクエスト
- アクセストークンリクエスト/レスポンス
- トークンイントロスペクションリクエスト/レスポンス