Rich authorization request (RFC 9396)

[vivshankar]

Preflight checklist

• [X] I could not find a solution in the existing issues, docs, nor discussions.
• [X] I agree to follow this project's Code of Conduct.
• [X] I have read and am following this repository's Contribution Guidelines.
• [X] I have joined the Ory Community Slack.
• [X] 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.

[github-actions[bot]]

Hello contributors!

I am marking this issue as stale as it has not received any engagement from the community or maintainers for a year. That does not imply that the issue has no merit! If you feel strongly about this issue

• open a PR referencing and resolving the issue;
• leave a comment on it and discuss ideas on how you could contribute towards resolving it;
• leave a comment and describe in detail why this issue is critical for your use case;
• open a new issue with updated details and a plan for resolving the issue.

Throughout its lifetime, Ory has received over 10.000 issues and PRs. To sustain that growth, we need to prioritize and focus on issues that are important to the community. A good indication of importance, and thus priority, is activity on a topic.

Unfortunately, burnout has become a topic of concern amongst open-source projects.

It can lead to severe personal and health issues as well as opening catastrophic attack vectors.

The motivation for this automation is to help prioritize issues in the backlog and not ignore, reject, or belittle anyone.

If this issue was marked as stale erroneously you can exempt it by adding the backlog label, assigning someone, or setting a milestone for it.

Thank you for your understanding and to anyone who participated in the conversation! And as written above, please do participate in the conversation if this topic is important to you!

Thank you 🙏✌️