[thiva-k]

Purpose

Adds Rich Authorization Requests (RFC 9396) support to the JavaScript SDKs: clients can request authorization_details and read what was granted, and the React consent UI renders authorization details with the changes a user may make to them.

runtime-consent-1.5x.mp4

Approach

• Request and token (@thunderid/javascript, browser, node, express):
  • New authorizationDetails config key and per-call option, sent JSON-encoded as authorization_details on the authorization request, the CIBA backchannel request (initiateCIBA) and the client_credentials token request.
  • Object values in authorize parameters are JSON-encoded.
  • Granted details are surfaced as TokenResponse.authorizationDetails and in session data (node signIn, express onSignIn). Browser apps read the access token's authorization_details claim.
• Consent (@thunderid/javascript, react):
  • Consent models for the authorization details purpose (one element per detail, with its summary and rows).
  • Shared helpers in the core package, used by React, Vue and Nuxt: per-element decisions with the user's changes (getConsentElementDecision, getConsentModifiedValues) and form keys scoped by purpose. Field input parsing, validation and list toggling stay private to the React hook, and the display helpers live in React utils.
  • Following the existing Consent / ConsentCheckboxList split, React gets headless pieces (ConsentAuthorizationDetail, useConsentDetailField, isConsentApprovalBlocked and isApprovalBlocked on Consent) and a default UI built on them. A field keeps what the user types, writes a value only when it is valid and within its bound, and shows an inline error otherwise; approval is blocked while a field is invalid, and denial always works.
  • SignIn, BaseAcceptInvite and AuthOptionFactory keep their existing decision building; detail elements additionally carry the user's changes (modified), and the new form keys are removed before submission. Attribute and permission decisions are unchanged.
  • Translations for all locales.
• Vue and Nuxt: they don't render consent today. Their existing decision building also handles detail elements, so a detail is never approved unless the application sets it, and Vue forwards authorizationDetails on sign-in.
• Scope: consent for authorization details is rendered by the authorization server's own UI (hosted login). App-native flows cannot carry authorization details.

Demo

Sign-in from a sample app, the processor adjusting the request, and the consent screen rendered with the new headless pieces: a value outside its policy blocks approval, the user narrows the amount and removes an action, and the token carries only what was approved.

[Video placeholder: drag runtime-consent.mp4 here]

Related Issues

• Support Rich Authorization Requests (RFC 9396) in ThunderID thunderid#5155
• Port Rich Authorization Requests request support to the remaining SDKs thunderid#6012 (port to the remaining SDKs)

Related PRs

• Add Rich Authorization Requests backend thunderid#5933 (backend)
• Add rich authorization details management layer thunderid#6009 (authorization details type registry)
• Add Rich Authorization Requests specification thunderid#5691 (specification)
• Add Rich Authorization Requests threat model thunderid#5692 (threat model)

SDK parity

• android-sdks: consent rendering not applicable (the SDK renders no consent prompts). Request and token response support deferred: Port Rich Authorization Requests request support to the remaining SDKs thunderid#6012
• ios-sdks: consent rendering not applicable (no consent prompts). Request and token response support deferred: Port Rich Authorization Requests request support to the remaining SDKs thunderid#6012
• flutter-sdks: consent rendering not applicable (no consent prompts). Request and token response support deferred until the Android and iOS SDKs ship it: Port Rich Authorization Requests request support to the remaining SDKs thunderid#6012
• python-sdks: consent rendering not applicable (no UI). Request and token response support deferred: Port Rich Authorization Requests request support to the remaining SDKs thunderid#6012

Checklist

• Followed the contribution guidelines.
• Manual test round performed and verified.
• Documentation provided. (Add links if there are any)
• Tests provided. (Add links if there are any)
  • Unit Tests
  • Integration Tests
• Breaking changes. (Fill if applicable)
  • Breaking changes section filled.
  • breaking change label added.
• Cross-SDK parity. Exactly one of parity/prs-raised or parity/prs-not-needed added.
  • If parity/prs-raised, the port links are posted as a reply on the parity check's comment.

Security checks

• Followed secure coding standards.
• Confirmed that this PR doesn't commit any keys, passwords, tokens, usernames, or other secrets.

[github-actions]

🔀 Cross-SDK feature parity, ports raised

This pull request is labelled parity/prs-raised, so the capability it introduces is expected in the other ThunderID SDKs as well.

Ports (DO NOT EDIT)

• thunder-id/ios-sdks, iOS => does not apply
• thunder-id/android-sdks, Android => does not apply
• thunder-id/flutter-sdks, Flutter => does not apply

3 of 3 sibling SDKs accounted for.

Every sibling SDK is accounted for.

The contract is in the SDK development specification.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[thiva-k]

Ports for the request-side capability (sending authorization_details and surfacing the granted details) are deferred and tracked in thunder-id/thunderid#6012. Consent rendering of authorization details does not apply to these SDKs, since none of them renders consent prompts.

• thunder-id/ios-sdks: deferred, Port Rich Authorization Requests request support to the remaining SDKs thunderid#6012
• thunder-id/android-sdks: deferred, Port Rich Authorization Requests request support to the remaining SDKs thunderid#6012
• thunder-id/flutter-sdks: deferred, Port Rich Authorization Requests request support to the remaining SDKs thunderid#6012