Spring-security: Provide support for OAuth 2.0 Token Exchange for client

Created on 3 Apr 2018  路  12Comments  路  Source: spring-projects/spring-security

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

Related #6053

oauth2 enhancement

Most helpful comment

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

All 12 comments

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

@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?

@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).

@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?

@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.

@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.

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.

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

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

@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.

@jgrandja Does this issue get resolved now?

@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.

Was this page helpful?
0 / 5 - 0 ratings