Implement RAR

[leastprivilege]

RFC 9396 - OAuth 2.0 Rich Authorization Requests (RAR) is a relatively new specification that allows fine-grained authorization data to be included in OAuth messages.

We are considering implementing RAR in a future release. Please upvote this feature to help us gauge interest and prioritize it. Alternatively you can contact us if this is a must have for you.

We would also like to hear about your use cases. Your feedback can help us shape the design of RAR in IdentityServer. Please take a look at this comment - any feedback you can provide about how you would like to use RAR is greatly appreciated!

[ahaeber]

The RFC Editor published an RFC for this draft earlier this year: RFC9396 "OAuth 2.0 Rich Authorization Requests" https://datatracker.ietf.org/doc/html/rfc9396

[brockallen]

Considering for version 8.0.

[maartenba]

(note: we are moving this issue to the new Developer Community discussions)

[vpetrusevici]

Hello!
Do you have this implementation in plans for near future? It would be awesome to use it in our bank authorization processes
Thank you!

[RolandGuijt]

It's not on our roadmap right now unfortunately. I've changed the original post with an invitation to vote through. We would like to gauge interest in this. If you'd like to discuss this further feel free to contact us.

[chana-Auerbach]

As a fintech company, implementing RAR is essential for us.
Would you kindly reconsider adding this feature to your upcoming backlog?
Thank you!

[josephdecock]

While we aren't ready to commit to a specific release for RAR, we are considering it in our research and planning. Community feedback will help us shape what RAR support ultimately looks like, so I'd love to hear more about your use cases.

[josephdecock]

We’d love feedback from anyone interested in RAR support—your input will help shape the feature!

• What programming model would you prefer for authorization_details? Just raw access, or an object model?
• How much variety do you have in authorization_details? Can they be represented by one type, a few (5–10), or many (dozens+)?
• Should business rules and validations for authorization_details be part of the IdentityServer config (similar to how clients have allowed scopes), or implemented in code?
• Do you need to support both scopes and authorization details in the same token request?
• Do you need to display authorization details on the consent screen?

[vpetrusevici]

I'm working on bank mobile app and we are going to use RAR for transactions authorizations.

1. JsonArray (because authorization_details is an array of objects be standard) would be enough in our case
2. Can be different for each operation type, will have only several common fields. Currently 5 operations
3. For me something like "EnableAuthorizationDetails" would be enough and have received details as separate field in authorization context and etc.
4. Not in our case. Authorization details is an alternative of scopes for me.
5. Yes, we even implemented it by ourselves using custom interaction flow for redirection. That's the main reason - to show authorization details in the single trusted place, so user can read and confirm.

[vpetrusevici]

Another use case is OpenBanking implementation by BerlinGroup standard. It supports OAuth2 with RAR to authorize user's transactions and consents initiated by third party.