userの代理ではない

Indexerは全ノートの検索indexを更新するbackend jobです。Resource Ownerの操作を代理するのではなく、Indexer Client自身の権限でnotes:indexを実行します。

POST /api/auth/oauth2/token
Authorization: Basic base64(client_id:client_secret)
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&
scope=notes%3Aindex&
resource=http%3A%2F%2F127.0.0.3%3A4300

Tokenのprincipalはuserではなくclientです。RSはclient_idまたはazpを検証済みclaimから取り、/index routeではuser Tokenを拒否します。

scope ceilingを登録時に決める

Client registrationにはclient_credentials_scopes: ['notes:index']を設定します。Requestでnotes:read notes:writeを送っても、登録時のceilingを超えられません。

Consent画面はありません。AS operatorがClientを登録しsecretを渡した時点でpolicy decisionが済んでいます。そのためClient Secretの配布、rotation、失効、auditがResource Owner Consentの代わりに重要になります。

Basic認証を正しく作る

Client IDとsecretを単純にcolon結合する前に、OAuth form encoding規則を適用します。HTTP Basic headerをlogへ出しません。

const credentials = Buffer.from(
  `${encodeURIComponent(clientId)}:${encodeURIComponent(clientSecret)}`,
  'utf8'
).toString('base64')

client_secret_postもProviderは対応しますが、同じClientが登録方式と異なるmethodを使えば拒否します。複数methodを同時に送るrequestも曖昧なので拒否対象です。

secretをrepositoryへ入れない

seed時のClient Secretは.local/clients.jsonへmode 0600で保存します。consoleに値を出さず、Indexerもfingerprintだけを表示します。本番ではsecret managerからprocessへ注入し、fileへ永続化しません。

Client SecretをReactへ移すとClient Credentialsが使えるようになる、という考えは誤りです。Browser利用者全員へ同じcredentialを配布することになり、Clientの認証になりません。

failureを観測する

secretを1文字変更 → invalid_client
notes:writeを要求 → invalid_scope
Basic登録Clientがbodyにsecretを送る → method mismatch
得たTokenでuser用POST /notes → service principal policyで拒否
user Tokenで/index → service principal required

次章では、Client Secretを持てず、入力も難しいDevice Clientを扱います。