keycloak
Support RFC 8707
Description
Currently Keycloak supports audience parameter to indicate the target resource (client) that the token will be used for (https://www.keycloak.org/docs/latest/securing_apps/#form-parameters). However according to RFC 8707 the parameter to indicate target resource should be resource.
Discussion
No response
Motivation
improve standard compliance
Details
No response
@yohny I think your wording is a bit misleading. Keycloak uses the audience claim to denote the resource server that should use it to check whether the token is intended for him. Having an additional optional resource parameter according to RFC 8708 would be an additional feature, the audience claim would still stay the same.
isn't that exactly what rfc 8707 says that resource parameter should be used for?
the resource server should always check the aud claim (intended audience) of a token to check whether the token is for it or not (and refuse processing if its not)
the rfc 8707 specifies that client should use resource parameter when requesting tokens to idicate for which resource server (another client) the token will be used for... and as far as I can tell this is what audience parameter is doing now, or am I missing something?
Its actually giving the resource server (aud) an indication of which resource on the resource server.
Its actually giving the resource server (aud) an indication of which resource on the resource server - assuming there are multiple resources. It is somewhat similar to the scope parameter.
I might be reading it wrong, but I dont see anywhere in the specification that resource should indicate a "sub-resource" within a resource server; quoting from spec:
When the resource parameter is used in an authorization request to the authorization endpoint, it indicates the identity of the protected resource(s) to which access is being requested
When the authorization server is informed of the resource that will process the access token, it can restrict the intended audience of that token to the given resource such that the token cannot be used successfully at other resources
and specific section about access token
When the resource parameter is used on an access token request made to the token endpoint, for all grant types, it indicates the target service or protected resource where the client intends to use the requested access token.
to me that seems quite similar to current audience behavior, with the distinction that you dont put there client id, but absolute URI instead (which can be then mapped to client id, as stated in the last sentence in the quote below) from here
The authorization server SHOULD audience-restrict issued access tokens to the resource(s) indicated by the resource parameter. Audience restrictions can be communicated in JSON Web Tokens with the aud claim and the top-level member of the same name provides the audience restriction information in a Token Introspection response. The authorization server may use the exact resource value as the audience or it may map from that value to a more general URI or abstract identifier for the given resource.
P.S. specification seems to also allow the use of abstract identifiers instead of ansolute URI in resource parameter here, which makes it even more similar to current audience parameter
Whenever feasible, the resource parameter should correspond to the network-addressable location of the protected resource. This makes it possible for the client to validate that the resource being requested controls the corresponding network location, reducing the risk of malicious endpoints obtaining tokens meant for other resources. If the resource parameter contains an abstract identifier, it is the client's responsibility to validate out of band that any network endpoint to which tokens are sent are the intended audience for that identifier.
In my understanding, RFC 8707 is an addition to what is currently available. It won't replace what is currently there, especially not the audience claim. So if you have a good use case why you need this supported, just go ahead.
My intention is not to replace audience parameter as that would be a breaking change to many clients. Instead I would like the resource parameter to be added (perhaps as an alias to audience) to have better compliance with standards.
That's totally fine. You might want to start a discussion first to check if anybody else is interested and if you could join forces to provide an implementation for this.
Resource indicators would be useful to a client that is accessing multiple resource providers to be able to obtain tokens with a smaller scope basically. Very similar to scope just with a bit of a different syntax.
For example myclient could have access to api-1 and api-2, which would result in access tokens having aud: [api-1, api-2]. However, myclient doesn't always want to send an access token to api-1 that api-1 could then use to access api-2.
In addition it can also scope a token to a sub-resource within the resource server.
I'd argue that resource should not be included in the access token, but rather used to control what aud and scopes are included in the token. Making it transparent to the resource providers.
One problem is that it leverages URIs instead of client-ids, which means there would need to be some mapping. That could be done through looking at the clients configured for the full audience, and removing any that doesn't have a URL that matches the URIs requested in the resource parameter.
To allow sub-resources I would imagine you'd want to map a sub-resource to a scope rather than an audience. So for example resource=https://myapi could result in an access token with aud=myapi, while resource=https://myapi/galleries would result in an access token with aud=myapi and scope galleries, or something along those lines.
It's also worth mentioning that this use-case can also be handled with scopes themselves in Keycloak. You can have scopes like api-1, api-2, api-2:galleries, and then rather than using resources use scope. Not sure if Keycloak supports this, but strictly speaking according to the spec you can use a refresh token to obtain an access token with a smaller scope.
End of the day I think we could support resource param as well in Keycloak fairly easily by just mapping it to aud and scopes.
@stianst @mposolda as I understand Keycloak intends to support RFC 8707 Resource Indicators for OAuth 2.0 as a protocol mapper ( resource to aud and/or scope). This is great news. We have opened a PR with different logic for this. Now, we can not procceed with a PR with the logic you mentioned. However, we are also interesting in this feature and it would be useful if someone could make a PR.
We want only to mention that we believe that aud could be either the resource as it is (URL) or a mapping client id as you mentioned. This is based on the RFC 8707 specification :
The authorization server may use the exact resource value as the audience or it may map from that value to a more general URI or abstract identifier for the given resource.
Moreover, JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens mentions aud as required parameter in access token. We have proposed also Keycloak supporting this with an optional default value (no migration needed). This was part of our related closed issue. Do you want to open a new issue for this?
I'm reading this discussion and it confuses me a bit. It seems like keycloak correctly implements the audience parameter for token exchange, according to RFC8693. This is a completely different problem from implementing RFC8707, which extends RFC6749 to add the resources parameter to the authorization requests and token requests. Why did RFC8707 and RFC8693 decide on two different parameter names and format for basically the same goal is a mystery for me. However, just making audience a synonym to resources (as proposed in this discussion thread) doesn't seem correct.
Keycloak also implements the audience field for the UMA grant type. This is probably a non-standart extension, because I couldn't find any standart mentioning it. This is probably similary to how auth0 allows the audience parameter for the token requests without it being part of any standard I could find (if you know about one, please point it to me).
