Clientを信頼する画面ではない

Consentは「このアプリを信頼しますか」という曖昧な確認ではありません。Client、Resource、要求scope、既存grantとの差分をResource Ownerへ示し、今回委譲する集合を確定する操作です。

ASが持つscope catalogは次の情報を返します。

{
  name: 'notes:write',
  label: 'ノートを編集',
  description: '新しいノートを作成し、既存ノートを更新します',
  risk: 'high'
}

Clientがquery parameterでlabelを送る構成にすると、notes:writeを「表示設定」などと偽装できます。scope identifierと説明の対応はASが所有します。

requiredとoptionalを分ける

Provider clientのconsent APIから、要求scopeと選択可能性を受け取ります。UIはrequired scopeを外せないようにし、optional scopeだけcheckboxで選べるようにします。

await authClient.oauth2.consent({
  accept: true,
  scope: [...selectedScopes].join(' '),
  oauth_query: oauthQuery
})

拒否を選んだ場合はaccess_deniedをClientの検証済みRedirect URIへ返します。Client側はこれをnetwork errorとして扱わず、Resource Ownerが認可しなかった結果として表示します。

oauth_consentはuserとclientの組に対する承認scopeを保持します。Access Tokenそのものではありません。Tokenを失効させても、同じscopeの再認可でConsent画面を省略できる場合があります。逆にConsentを削除しても、すでに発行済みTokenの状態を別途扱う必要があります。

ここから次の3つを分けられます。

authorization decision: 何を許可したか
credential: その決定を提示するAccess Token
session: Resource OwnerがASへログイン中か

step-upを観測する

最初にnotes:readだけを認可します。後で「ノート作成」を選んだとき、新しいAuthorization Requestにnotes:writeを加えます。

ASは以前のConsentがあるからといって、新しいscopeを黙って追加しません。差分のnotes:writeを確認させ、更新されたConsentを保存します。Client側のbuttonをdisabledにするだけでは権限制御にならないため、RSもnotes:writeを検証します。

scope名の設計

readのような短い名前は別Resourceと衝突します。ラボはnotes:read、notes:write、notes:indexとdomainを含めます。notes:indexはResource Ownerのdelegated scopeではなく、Indexer Clientだけに許すClient Credentials scopeです。

OIDCのopenid、profile、email、offline_accessはPart 4で意味を追加します。今は同じspace-separated文字列に見えても、scopeごとに発行物とpolicyが違うことだけ覚えておいてください。

次章ではConsent結果から短寿命・一回限りのAuthorization Codeを作ります。

Clientを信頼する画面ではない

requiredとoptionalを分ける

Consent recordの意味

step-upを観測する

scope名の設計