OAuth 2.1 の主要な変更ポイントと、非推奨となるフロー

OAuth 2.1 とは？

OAuth 2.1 は、API認可のデファクトスタンダードである「OAuth 2.0（RFC 6749）」の次期バージョンとして、IETF（Internet Engineering Task Force）で策定が進められている規格です。

名前に「2.1」とある通り、OAuth 3.0のような全く新しい技術へのフルリニューアルではありません。 OAuth 2.0が2012年に発行されてから10年以上の間に、セキュリティのベストプラクティス（BCP：Best Current Practice）や新たな拡張仕様が数多く生まれました。OAuth 2.1は、これらの**「最新の常識と推奨設定を取り込み、危険な古い仕様を削除して整理したもの」**です。

OAuth 2.1 における主要な変更ポイント

OAuth 2.1の目的は「より安全に、よりシンプルに」することです。主な変更点は以下の通りです。

1. PKCE (Proof Key for Code Exchange) の必須化

OAuth 2.0の「認可コードフロー」において、これまではモバイルアプリ等でのみ推奨されていたPKCE（ピクシー）というセキュリティ機能が、Webアプリを含むすべてのクライアントで必須となります。 PKCEは、認可コードが通信経路上で悪意のあるアプリに盗聴・奪取（Authorization Code Interception Attack）された場合でも、アクセストークンを不正取得されないようにするための暗号学的な防御策です。

2. 「インプリシットフロー」の非推奨・廃止

OAuth 2.0には、サーバーサイドを持たないブラウザ上のアプリ（SPAなど）向けに「インプリシットフロー（Implicit Flow）」が存在していました。これはアクセストークンをURLのフラグメント（#以降）に入れてブラウザに直接返す仕組みでしたが、URL履歴に残るなど漏洩リスクが高いものでした。 OAuth 2.1ではこのフローが完全に非推奨となり、SPAであっても前述の「PKCE付き認可コードフロー」を使用することが義務付けられます。

3. 「リソースオーナーパスワードクレデンシャルグラント」の廃止

ユーザーがIDとパスワードをアプリに直接渡し、アプリがそれを使ってトークンを取得するフロー（ROPCフロー）が廃止されます。このフローはアプリにパスワードを渡すため、OAuth本来の「パスワードを渡さずに権限を委譲する」という目的に反しており、重大なセキュリティリスクであるためです。

4. 完全なリダイレクトURIの一致確認

セキュリティを高めるため、認可リクエスト時とトークンリクエスト時のリダイレクトURIが「完全（Exact Match）」に一致していることが厳密に求められるようになります。

開発者が今すべきこと

OAuth 2.1は全く新しい技術ではないため、「今すぐシステムを作り直さなければならない」という類のものではありません。現在、セキュリティを意識して設計された先進的なシステム（IdP）は、既に実質的にOAuth 2.1に準拠した挙動をしています。

しかし、もし現在管理しているシステムがインプリシットフローを使用していたり、PKCEを実装していない場合は、早急に「PKCE付き認可コードフロー」への移行を計画する必要があります。OAuth 2.1の動向を追うことは、そのまま自社システムのセキュリティ向上に直結します。