OAuth 1.0から2.1への展開の道のり

背景

2010年にOAuth Authorization Specification version 1.0 (rfc 5849) が公開され、その2年後に、よりシンプルで使いやすいOAuth 2.0 仕様が公開され (rfc 6749) 、インターネット上で最も身近で広く使われているバージョンになりました。当時は "Ajax applications" と呼ばれ、CORS (Cross-Domain Resource Sharing) はまだ W3C の標準規格ではありませんでした。

このような状況の変化に対応するため、OAuth コミュニティは何年も前から OAuth 仕様にパッチを当て、拡張してきました。OAuth の状況は拡大し、OAuth 2.0 を中核とする拡張認可仕様がどんどん登場しています。そして、OAuth 2.0全体がまるで迷路のように見えるのです。

進化するOAuth2.0

OAuth 2.0のコア仕様（RFC 6749）では、以下のように、認証コード、暗黙の了解、パスワード、クライアント認証の4種類の認証が定義されています。

OAuth 2.0では、最も安全でよく使われるモデルは認証コードモデルです。ローカルアプリ、モバイルアプリの場合、通常は暗黙の認証やパスワード認証を使います。これらはパブリッククライアントなので、本質的に安全ではなく、クライアントの機密を守ることはできませんが、他に良い解決策がなかったのでしょう。

OAuth 2.0のパブリッククライアントの認証セキュリティ問題を解決するために、Proof Key for Code Exchangeと呼ばれるPKCE (RFC 6379) プロトコルが作られました。PKCEの原理は、パブリッククライアントに対して、client_secretが使用できない場合、クライアントは自分で作成した証明（code_verifier）を認可サーバーに提供し、認可サーバーはその暗号化アルゴリズムを使ってクライアントを確認するというものです。

その後、「OAuth 2.0 for Native Apps" (RFC 8252)」という仕様が公開され、ネイティブアプリでも認証コード＋PKCEを使うことが推奨されるようになった。

テクノロジーの進化に伴い、スマート TV やプリンターなどのデバイスは、従来の PC や電話とは異なり、ブラウザやキーボードがないため、OAuth 2.0 の通常の認証モデルでは間違いなく不十分であり、そのため Device Grant というデバイス認証シナリオが登場します。

OAuth 2.0 セキュリティベストプラクティス（セキュリティBCP）では、暗黙の了解とパスワードによる認証は非推奨とされ、すべてのクライアントが認証コード＋PKCEの組み合わせを使用することが推奨されています。

最終的に、調整されたOAuth認証モデルは、OAuth2.1の考え方である、セキュリティベストプラクティス（BCP）を参考に、最良のものを取り入れ、最悪のものを取り除く、以下の3つに変換され、より合理的なものになるでしょう。

概要

結局、OAuth 2.1はOAuth 2.0を覆すものではなく、安全でない認可処理を取り除き、そのセキュリティベストプラクティス（BCP）に基づいた拡張機能を統合し、迷宮のように複雑だったOAuth 2.0仕様をより簡単で安全な認可仕様にするためのものです。

参考文献

OAuth 1.0 プロトコル
OAuth 2.0認証フレームワーク
OAuth 2.1 認証フレームワーク draft-ietf-oauth-v2-1-04
OAuth 2.1の時代がやってきた
ネイティブアプリ向けOAuth 2.0
OAuth 2.0 デバイス認証グラント
OAuthパブリッククライアントによるコード交換のための証明キー

以上が今回の記事の全内容です。皆様の学習のお役に立てれば幸いです。また、スクリプトハウスを応援していただければ幸いです。