BrowserをASへ移動させるrequest

Public Clientが最初に行うのはAPI callではなく、Resource OwnerのBrowserをAuthorization endpointへ移動させることです。

GET /api/auth/oauth2/authorize?
  response_type=code&
  client_id=...&
  redirect_uri=http%3A%2F%2F127.0.0.1%3A4200%2Fcallback&
  scope=notes%3Aread&
  state=...&
  code_challenge=...&
  code_challenge_method=S256

response_type=codeは、TokenではなくAuthorization Codeをredirectで受け取る指定です。client_idは公開情報であり、Client Secretの代わりではありません。redirect_uriは事前登録値と完全一致させます。

Authorization Code + PKCEのprotocol flow

scopeは集合として要求する

最初はnotes:readだけを要求します。

const scope = new Set<string>(['notes:read'])

if (needsWrite) scope.add('notes:write')
if (needsLongLivedAccess) scope.add('offline_access')

「このアプリが将来使うかもしれない権限」ではなく、「今回の機能に必要な権限」を送ります。書込み操作を選んだ時点でnotes:writeへstep-upするため、Consent画面の変化も観測できます。

stateとtransactionを作る

stateはBrowserを往復したresponseを、開始したClient transactionへ結び付けます。ランダム文字列を比較するだけでは足りません。どのissuer、redirect URI、PKCE verifier、OIDC nonceと組み合わせた値かを保存します。

const transaction = {
  id: randomBase64Url(18),
  state: randomBase64Url(32),
  codeVerifier,
  issuer: AUTH_ISSUER,
  redirectUri,
  startedAt: Date.now()
}

ラボはこれをsessionStorageへ保存します。callbackでstateからtransaction IDを引き、recordを読み出した直後に両方のkeyを削除します。10分を超えたtransactionも拒否します。

stateをAccess Tokenの代用品にしたり、利用者情報を埋め込んだりしません。十分なentropyを持つ相関identifierです。

Better Authの入口

Providerのauthorize処理はqueryとform POSTを同じ内部形式へ正規化し、requestとrequest_uriの競合、Client、Redirect URI、response type、scope、resource、PKCEを検証します。

認可requestに構文エラーがあっても、未検証のredirect_uriへerrorを返してはいけません。まずClientとRedirect URIを確定できた場合だけredirect responseを使い、それ以前のerrorはAS自身のresponseとして返します。

失敗させて役割を確認する

client_idを未知の値へ変える → Clientを特定できない
redirect_uriの末尾slashを変える → 完全一致せず拒否
notes:adminを加える → invalid_scope
code_challenge_method=plainへ変える → S256 policyに反する
response_type=tokenへ変える → Implicit Flowを提供しない

URLのparameterをClient側だけで検証しても安全性は上がりません。最終的なpolicy ownerはASです。次章では、AS sessionがない場合にOAuth transactionを失わずログインへ移る仕組みを見ます。