Rich authorization request (RFC 9396)

[vivshankar]

Preflight checklist

• I could not find a solution in the existing issues, docs, nor discussions.
• I agree to follow this project's Code of Conduct.
• I have read and am following this repository's Contribution Guidelines.
• I have joined the Ory Community Slack.
• I am signed up to the Ory Security Patch Newsletter.

Ory Network Project

No response

Context and scope

Support fine-grained authorization details using Rich Authorization Request RFC9396.

Goals and non-goals

Goals:

• Support RAR within Fosite
• Provide a framework to define custom authorization detail types

Non-goals:

• Exhaustive set of custom authorization detail types

The design

RAR offers a standards-based mechanism to represent fine-grained authorization details as JSON objects, as opposed to scopes that are used for course-grained permissions.

Given the standard offers no prescriptive list of attributes that should make up the JSON object, other than the type, this implementation seeks to stop at providing the framework to define custom objects. authorization_details typically shows up wherever scope would be and, while is not required to co-exist with scopes, will co-exist in this implementation. This is because authorization details are more verbose and have the counter-effect of inflating the size of the JWT access token or the introspection response. Scopes may very well fit certain use cases and should co-exist in the same request.

The following are proposed to be added:

• Authorization detail object represented as a struct with Extra for non-prescribed attributes.
• Authorization detail type decorator that adds Equals and Validate logic. This is associated with a specific type, such as payment_initiation. This allows for customized logic to be built based on the type of the authz detail.
• Configuration parameters to get the list of authorization detail types supported by the authorization server, a map of type decorators/handlers, a comparison strategy similar to ScopeStrategy, etc.
• New handler type called the AuthorizeEndpointValidationHandler that is executed in newAuthorizeRequest. This is introduced to provide a mechanism similar to HandleTokenEndpointHandler, which is executed during the request validation and to enrich the requester. The current HandleAuthorizeEndpointHandler mirrors the PopulateTokenEndpointResponse. This allows us to get a handle on the ever-growing authorize_handler and to offer a future path to make this part of Fosite more modular.
  • For example, consider a future enhancment where the handling of the request object is moved into a handler because different implementations may choose to use different methods to validate the incoming JWT. (This is an example. Not for discussion.)

APIs

No response

Data storage

No response

Code and pseudo-code

No response

Degree of constraint

No response

Alternatives considered

No response

[vivshankar]

@aeneasr I already have an implementation available, so I can contribute this once (and if) I get a green light.

Candidate implementation (on my fork) for your reference - https://github.com/vivshankar/fosite/pull/29/files

[aeneasr]

Hey - this makes sense to us! Depending on complexity review may need to wait until we have resources available (happens primarily when a prospect or customer asks for it)

[vivshankar]

@aeneasr Sure. Please let me know when there is interest and time, and I will work on the PR submission at that point.