Support RFC 8707, resource indicators

[mooreds]

Support RFC 8707, resource indicators

Problem

An access token can be presented to any resource server. This is an issue if the token is exfiltrated.

Solution

Have clients provide information about which resource server they are requesting access to, using standards.

Alternatives/workarounds

n/a

Additional context

Here's the RFC: https://datatracker.ietf.org/doc/html/rfc8707

Community guidelines

All issues filed in this repository must abide by the FusionAuth community guidelines.

How to vote

Please give us a thumbs up or thumbs down as a reaction to help us prioritize this feature. Feel free to comment if you have a particular need or comment on how this feature should work.

[robotdan]

This sounds similar to the aud claim - but perhaps more specific? Could this be handled using a JWT populate lambda? Unless FusionAuth adds configuration to know what resources to add, you'd have to do this in a lambda anyway, so perhaps that is the best place for it?

[mooreds]

It's more specific in that the client actually registers intent to make a request of a certain resource in both the authorize and the token call.

The [resource] parameter value identifies a resource to which the client is
requesting access. The parameter can carry the location of a
protected resource, typically as an https URL or a more abstract
identifier. This enables the authorization server to apply policy as
appropriate for the resource, such as determining the type and
content of tokens to be issued, if and how tokens are encrypted, and
applying appropriate audience restrictions.

This would allow for finer grained access than at the aud/application level (which is what we currently support). For example, if I had a FusionAuth application of customapp which represented an API at http://exampleapp.com/, I might have different clients that are accessing it. An admin client might need to access http://exampleapp.com/admin/api and a normal client might need to access http://exampleapp.com/api/ . Supporting this spec would mean that clients could provide the resources they wanted to access, and that we could have different rules for them. (Group membership or IP ACLs, for example.)