はじめに

OAuth2.0を扱っていて1st PartyのSPAの場合とかどうするのが良いのか悩んでいたら出会ったので訳してみました。

原文はコレ
https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-06

訳してみましたというレベルではないくらい原文に忠実ではありませんが、雰囲気重視の人の参考になればいいかなと思います。

概要

この仕様はブラウザーベースのアプリケーションのベストプラクティス

このメモのステータス

ドラフトなので最長6ヶ月単位くらいで見直される
- 更新されるかもしれないし、置き換えられたり、他のドキュメントによって非推奨になったりし得る

イントロ

この仕様はブラウザで実行されるアプリケーションにおいてOAuth2.0のAuthorizationフローを実装するための現時点でのベストプラクティス
ネイティブアプリの話は別口RFC8252で定義されている
- AppAuthという愛称で呼ばれている
App Authとよく似ているけどブラウザベースのアプリケーション固有の考慮が追加されている

用語

OAuth
- このドキュメントの中ではOAuth2.0 RFC6749, RFC6750のことを指す
Browser-based application
- Webブラウザによってダウンロードされて実行されるアプリケーション
- 大抵はJavaScriptで書かれたもの
- SPAとか

Overview

総括「イマドキのブラウザベースアプリのベストプラクティスは認可コードフローwithPKCE」

OAuth2.0が作られたときには認可コードフローはブラウザベースのJavaScriptアプリケーションでは使えないものとされていた
- same-origin ポリシーに準拠する前提
- 方やOAuth2.0では認可サーバーが別のドメインである前提
- クロスオリジンなPOSTリクエストが必要とされる
  - トークンエンドポイントのことを指していると思われる
- だから認可コードフローはできなかった
上記がインプリシットフローを定義した理由
- アクセストークンがリダイレクトされたURLの一部として得られる
- クロスオリジンなPOSTは必要ない
しかしインプリシットフローにはいくつか欠陥がある
- 一般的にはURL中のアクセストークンが奪われる系の攻撃
  - ブラウザでのこれらの攻撃については後で解説がある
- その他興味がある人はoauth-security-topicsを見てくれ
近年ではCORSが当たり前になってきた
- だからフツーに認可コードフローで良いんじゃないか
- クロスオリジンなPOSTでトークンエンドポイント叩いてもさ
  - トークンエンドポイントならセキュアだろう？（＝かなり意訳）
  - さらにPKCEに対応しておけばAuthorizationCodeを盗み見られても対策できるだろう

ブラウザベースアプリケーションのMUST

OAuth2.0の認可コードフロー + PKCE拡張を使う
CSRF攻撃対策として以下（要はワンタイムトークン)
- PKCEをサポートした認可サーバー
- OR OAuth2.0のstateパラメータを使う
- OR OIDCのnonceパラメータを使う

OAuth2.0認可サーバーのMUST

リダイレクトURIのマッチングは完全一致で確認すべし（ダメ前方一致）
PKCEをサポートせよ
リフレッシュトークンを発行する場合、
- 使用するごとにリフレッシュトークンはローテーション（毎回発行し直せということ）
- リフレッシュトークンには使用期限を設定せよ

1st-Party アプリケーション

元々OAuthは3rd-partyアプリケーションがユーザーに代わってAPIにアクセスするためのもの
でも1st-partyでも同じ様に有用
- 1st-partyアプリケーションはAPIとアプリケーションの提供元組織が同じという意味
  - XXX銀行APIを使う、XXX銀行公式アプリみたいなもの
1st-partyであっても認可コードフローのようなリダイレクトベースのフローにすべき
(「ような」って言っても結局認可コードそのものを使えって話)
- Resource Owner Password Grantは使うべきではない
  - 認可サーバーがユーザー認証するときに2FAの画面を出したりできる
    (Resource Owner Password Grantだと無理)
  - 他のIdPを使ったSSOも実現できる

ブラウザベースのアプリケーションのアーキテクチャパターン

JavaScriptアプリが同一サイトCookieなどでリソースサーバーとゴネゴネできるケース
- （要するに1st-partyでリソースサーバーとフロントエンドは同じドメインを想定していると思われる）
JavaScriptアプリがそいつ用のバックエンドを持っていて、そいつがリソースサーバーとアクセスするやつ
- （トラディショナルなWebApp+JSフロントみたいな感じで、ASP.Net+AngularとかSpring Boot+Reactとか）
純粋なJavaScriptアプリ(SPAかな)で、直接リソースサーバーにアクセスするやつ

1個めのパティーン

OAuthはそもそも3rd-partyアプリ用に作られたので、フロントエンドとリソースサーバーが同じドメインの場合にはベストとは言えないかもしれないが、OAuthを使っておくと後からドメインが追加になったときなどにつぶしが利くので結局のところOAuthを使っておいたほうがいい（と言っている気がする、なんとなく弱気な印象)

このパターンではOAuthは追加で別のソリューションが使える
- リダイレクトベースのフローはリダイレクトベースの攻撃を許してしまうが、
- 認可サーバーとリソースサーバーが同じドメインであればそもそもリダイレクトメカニズムを使う必要がない
  （ちょっと何言ってるのかわかんない）
もう一つ、ブラウザはアクセストークンをセキュアに保存する方法がない（この原稿を書いている日現在では）
- JavaScriptアプリでは取得したアクセストークンをどこかに保存して、APIリクエストする際にそれをとってくる必要がある
HTTP-only cookieを使えばそもそもJavaScriptはCookieにアクセスできないのでより安全
- 加えてSameSite cookieはCSRF攻撃を防ぐのにも使える
- またはCookieにCSRFトークンを入れるようにしてもいい

2個めのパティーン

このパティーンは要するにアプリケーション・サーバーがConfidential Clientという扱いなので認可コードフローを使うべき。

(A) 認可コードを使ってアクセストークンをサーバーサイドで要求する
(B) サーバーサイドでアクセストークンを受け取って保存する
- そのときにブラウザとの間にCookieベースのセッションを確立する
- アクセストークンの保存はサーバーサイドに保存してもいいし、Cookieに保存しても良い
(C) JavaScriptアプリがリソースサーバーにアクセスしたいときは、サーバーサイドが中継してリクエストしなければならない
(D) レスポンスも中継して返される

   +-------------+
   |             |
   |Authorization|
   |   Server    |
   |             |
   +-------------+

      ^     +
      |(A)  |(B)
      |     |
      +     v

   +-------------+             +--------------+
   |             | +---------> |              |
   | Application |   (C)       |   Resource   |
   |   Server    |             |    Server    |
   |             | <---------+ |              |
   +-------------+   (D)       +--------------+

       ^    +
       |    |
       |    | browser
       |    | cookie
       |    |
       +    v

   +-------------+
   |             |
   |   Browser   |
   |             |
   +-------------+

フロントエンドではなくて、アプリケーションサーバがOAuthフローを実行して、アクセストークンやリフレッシュトークンは「伝統的なブラウザCookieを使ったセッション」の仕組みで内部に保存できる
アプリケーションサーバはConfidential Clientとして考慮されるべきで自身のクライアントシークレットを保持する
ブラウザとアプリケーションサーバ間のセキュリティに関しては範囲外だから https://cheatsheetseries.owasp.org/ でも見とけ。
CookieのセッションIDとしてアクセストークンそのもの使う場合、エンドユーザーにアクセストークンそのものを見せちゃうから注意（JSアプリを使っていないときもブラウザに残る）

3個めのパティーン

このパティーンは要するにPublic Clientだから安全にクライアントシークレットを保持できない。故にクライアント認証の安全なメカニズムもない。

(A) JavaScriptのコードはスタティックなウェブホストからブラウザーにダウンロードされる
(B) ブラウザ上のコードが認可コードフロー+PKCEでアクセストークンを取得する
(C) トークンAPI(POST)のレスポンスとしてアクセストークンが得られる
(D) アクセストークンを付加してリソースサーバーにリクエストする
(E) レスポンスがもらえる

                         +---------------+           +--------------+
                         |               |           |              |
                         | Authorization |           |   Resource   |
                         |    Server     |           |    Server    |
                         |               |           |              |
                         +---------------+           +--------------+

                                ^     +                 ^     +
                                |     |                 |     |
                                |(B)  |(C)              |(D)  |(E)
                                |     |                 |     |
                                |     |                 |     |
                                +     v                 +     v

   +-----------------+         +-------------------------------+
   |                 |   (A)   |                               |
   | Static Web Host | +-----> |           Browser             |
   |                 |         |                               |
   +-----------------+         +-------------------------------+

このシナリオでは認可サーバーとリソースサーバーはCORSをサポートしていないといけない

認可コードフロー

パブリックなブラウザベースのアプリの認可コードフローではここで述べる追加の要件に従う必要がある

認可リクエストをブラウザからするとき

PKCEに対応しておく必要がある
- PKCEは認可コード奪取攻撃の対策

認可コードのリダイレクトを処理するとき

認可サーバーは完全一致で登録されたリダイレクトURIのチェックをすべし

リフレッシュトークン

リフレッシュトークンはアクセストークンの期限が切れたときにアクセストークンの再取得ができる方法
Public Clientではアクセストークンが漏洩するよりもリフレッシュトークンが漏洩するリスクのほうが大きい
- 攻撃者が継続的にリフレッシュトークンで新しいアクセストークンを取得し続けることができるから
認可サーバーとアプリはこのリフレッシュトークンに関してこのBCPのMUSTに準拠すべき
またoauth-security-topicsのリフレッシュトークン周辺のおすすめにも従うべき
特に認可サーバーは以下に従うべき
- リフレッシュトークンと使われるたびにローテーションされるべき
- 使用期限が設定されるべき
- ローテーションされるときにリフレッシュトークンの期限は延長されるべきではない

セキュリティ的考慮

ブラウザベースのアプリケーションはPublic Clientとして定義されていて、認可サーバーに登録されるべき
認可サーバーはクライアントタイプを記録してそれを識別すべき

クライアント認証

ブラウザベースのアプリのソースコードはブラウザーに配信されてしまうので安全にシークレットを持つことはできない、だからPublic Clientの扱いになる
- だれかがソースコードを解析してクライアントシークレットを引っこ抜いてばらまくこともできる
クライアントシークレットでは認証できずなりすましも可能

クライアントのなりすまし

認可サーバーは認可リクエストの処理をユーザーのconsent抜きで自動で行ってはならない
- クライアントのアイデンティティが保証されているなら別だけど
  (Public Clientではなりすまされるので無理と言っておいてなんでこの一文をかいたのか不明)

CSRF対策

クライアントは認可サーバー毎に一意なリダイレクトURIを使う必要がある
クライアントはリダイレクトURIをstateのようなセッションデータとともにほぞんする必要がある
そして認可レスポンスを受け取ったときにそのURIを完全一致で検証する必要がある

クロスドメインリクエスト

認可サーバーはCORSをサポートする必要がある
この仕様にはどのようなCORSポリシーにすべきかは含まれていない

Content-Security Policy

長期間寿命のリフレッシュトークンを使いたい場合、または特権スコープを使いたい場合Content Security PolicyのようなメカニズムでJavaScriptの実行を制限すべき

OAuth Implicit Flow

Implicit Flowの脆弱性などをずらずらと並べているが割愛

追加のセキュリティ考察

OWASP見とけ！