OAuth 2.1のドラフトにざっと目を通してみたので備忘録として残しておく。
現時点（2020–05–03）では、まだ個人ドラフト（draft-parecki-oauth-v2-1-02）の段階である。今後大幅に改訂される可能性が高いが、一方で、これまでのOAuth WGでの議論（OAuth 2.0 Security BCPなど）を通して、大まかな方向性は見えている状況でもある。したがって、早すぎるきらいはあるが、OAuth 2.1の骨子を大きくは外さないだろうと考えた。
要点
要は、OAuth 2.0の基本仕様であるRFC6749（OAuth 2.0 Authorization Framework）とRFC6750（Bearer Token Usage）に、RFC7636（PKCE）を合わせて、以下の3つのBCP（Best Current Practice）文書でフィルタリングしたものである。
- OAuth 2.0 for Native Apps（RFC8252）
- OAuth 2.0 for Browser-Based Apps
- OAuth 2.0 Security Best Current Practice
わかってはいたが、Authorization Code Grant と Client Credentials Grantの2つに絞られているのはスッキリしてよい（＝ Implicit GrantとResource Owner Password Credentials Grantが削除されている）。
PKCEがAuthorization Code Grantにおいて必須になっている。
Token利用時の仕様として、クエリ文字列にアクセストークンを入れて使う仕様（RFC6750の2.3節）が削除されている。
リフレッシュトークンの仕様が、セキュリティを考慮して具体化されている。具体的には、リフレッシュトークンをsender-constrained とするか、リフレッシュトークンのローテーション機構を導入しone-time useとするかしなければならない（MUST）。sender-constrainedにするには、mTLS、Token Binding、DPoP（まだOAuth 2.1ドラフトでは参照されていないが）等を使う必要がある。一方、リフレッシュトークンローテーションへの対応は、アクセストークンの更新時に一度使われたリフレッシュトークンを無効化するのは勿論だが、加えて、再利用された場合には全てのリフレッシュトークンを無効化する処置を行う必要がある。
OAuth 2.0 Security Best Current PracticeのRecommendationsが盛り込まれている。「認可サーバはリダイレクトURLの完全一致を確認しなければならない（MUST）」とか。
以上、実はOAuth 2.1の12章（Differences from OAuth 2.0）に概ねまとめられている。
所感
正直、OAuth 2.0 Security Best Current Practiceを読んでいると目新しさはなかった。
sender-constrained access tokenを推奨（SHOULD）しておきながら、使える＆固まっているソリューションがmTLSだけだとイマイチな感じがするので、他の方法がもう少し具体化され、絞り込まれるまで（例えば、DPoPの内容が固まるまで）、OAuth 2.1は時期尚早なのでは？と考えたりした。
エディトリアルな問題も多々あるし先は長そう。
