Provide support for OAuth 2.0 Token Exchange for client

[jgrandja]

We need to provide support for OAuth 2.0 Token Exchange RFC 8693

Related #6053

[William1104]

Hi,

This feature is removed from the 5.2.x milestone. May I know if any plan about this feature? Many thanks.

Thanks and regards,
William

[jgrandja]

@William1104 We are planning on implementing this feature but it may be too early at the moment until the spec goes through the review process further.

Instead we replaced this feature with #6053. As an FYI, you can also exchange a JWT token for another JWT using the JWT Bearer grant.

I'm curious, are you aware of any providers that have implemented OAuth 2.0 Token Exchange?

[mplukas]

@jgrandja

I'm curious, are you aware of any providers that have implemented OAuth 2.0 Token Exchange?

One example would be Keycloak (https://www.keycloak.org/):

Token exchange in Keycloak is a very loose implementation of the OAuth Token Exchange specification at the IETF (https://www.keycloak.org/docs/6.0/securing_apps/#_token-exchange).

[kdhindsa]

@jgrandja I am facing this problem where spring security isn't sending the scopes to auth server (azure). I traced it back to OAuth2AuthorizationCodeGrantRequestEntityConverter.java which is ignoring the "scope" and "resource" parameters that are present in the request parameter in that class.

Is there a way I can override this behavior?

[jgrandja]

@kdhindsa The issue you are having is not related to this issue (Token Exchange). Please post this question on StackOverflow or log a new issue if you believe this is a bug. Please see guidelines on using GitHub Issues.

spring security isn't sending the scopes to auth server (azure)

Have you configured the scopes property for the ClientRegistration?

Please see the reference doc for more details. I suspect there is a misconfiguration.

[kdhindsa]

@jgrandja, yes, I had configured the scopes correctly:

spring.security.oauth2.client.registration.azure.scope=openid,user.read,offline_access,files.read.all

but that didn't work. Eventually I found this configuration:

http.oauth2Login()
        .tokenEndpoint()
        .accessTokenResponseClient(aadAccessTokenResponseClient());

So I ended up creating my custom response client service which manually injects scopes:

public class AADOAuth2AuthorizationCodeGrantRequestEntityConverter
    extends OAuth2AuthorizationCodeGrantRequestEntityConverter {

  @Override
  public RequestEntity<?> convert(OAuth2AuthorizationCodeGrantRequest authorizationCodeGrantRequest) {
    RequestEntity requestEntity = super.convert(authorizationCodeGrantRequest);
    LinkedMultiValueMap<String, String> params = (LinkedMultiValueMap<String, String>)requestEntity.getBody();

    // FIXME: read from config
    params.put("scope", Arrays.asList("openid user.read offline_access files.read.all"));
    params.put("resource", Arrays.asList("https://graph.microsoft.com"));
    return requestEntity;
  }
}

and that worked.

[andifalk]

Hi @jgrandja, after lots of draft versions, the corresponding RFC 8693 standard for token exchange has finally been published this week (https://tools.ietf.org/html/rfc8693). So it would be great if you could schedule this in one of the next milestones.

[jgrandja]

Thanks for the heads up @andifalk. I don't think we'll be able to get this into 5.3 (due Mar 4) as we have other priority tasks that need to be completed. We'll likely target 5.4

[emedina]

This issue seems quite old now... Is this feature still in the roadmap for Spring Security?

https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-16

[jgrandja]

@emedina RFC 8693 was just published in Jan 2020, as mentioned in this comment. Now that it's published, we will see which providers implement to determine the appropriate time to implement on our end.

At the same time, features will get implemented quicker by the community via PR's as our team only has so much bandwidth. As of now, this feature is not scheduled for 5.4 but if a PR comes in then we will consider it then.

[ZxShirley]

@jgrandja Does this issue get resolved now?

[jgrandja]

@ZxShirley It's not scheduled as of yet. As mentioned in my previous comment...

...features will get implemented quicker by the community via PR's as our team only has so much bandwidth. As of now, this feature is not scheduled for 5.4 but if a PR comes in then we will consider it then.

We'll be prioritizing features when we plan for 5.5, which will be towards end of this month.

[muskiehunter1985]

Any update on when this will be prioritized as RFC 8693 was been defined for over a year now? Many providers are supporting this now such as keycloak, ping federate, etc.

[ciis0]

Token exchange is an extension for OAuth server, not a client-side thing. So if it's implemented in Spring ecosystem then it should be implemented maybe in Spring Auth Server

While I agree the server side would be implemented in Spring Authorization Server, I'd say there still is a client part -- having one token, getting another one -- which would be implemented in Spring Security (like other iteraction with the token endpoint, like Client Credentials or Refresh Token grant.)

I think the challenge is where to implement the client part. My ad-hoc implementation suggest at least the interceptors need to be aware of what the target audience/scopes is/are and use common logic (the TokenExchangeClient in my code) to actually exchange the token.

My client relies on the Authorized Client classes, which suggest that the common logic could be integrated there, maybe OAuth2AuthorizeRequest could be extended with attributes to enable token exchange? I think primarily about target audience/scope attributes, not sure about secondary ones.

[jgrandja]

@andifalk Thank you for providing the list of supporting providers.

Based on that, we will provide support for RFC 8693 OAuth 2.0 Token Exchange in Spring Security (client-side) and Spring Authorization Server (server-side).

However, I'm not sure yet if we can provide this new support in Spring Security 6.3 and Spring Authorization Server 1.3.

There are a couple of higher priority items that we need to deal with first and depending on when those complete we can then decide if this feature will get into the next release.

All I can say now is that we will do our absolute best and keep you all updated as we progress over the current release cycle.

[sjohnr]

Initial support is added via 85c3d0a. I've opened gh-14698 as a follow-up to add reference documentation, and hope to have a blog post available shortly as well.