Avoid hardcode URL for userAuthorizationUri and accessTokenUri

[kakawait]

On my project we have an UAA on same domain than OAuth2 Sso (via @EnableOauth2Sso).

Moreover to easily deploy application on every possible environment we try to do not have any absolute URLs.

Thus I want to know if is possible and not a no-sense to be able to configure OAuth2 client properties:

• security.oauth2.client.accessTokenUri
• security.oauth2.client.userAuthorizationUri

as path (!= absolute URL). Even more URI as describe on RFC is different than URL, path is an URI but when setting path I have following error:

java.lang.IllegalArgumentException: [/my/custom/path] is not a valid HTTP URL
    at org.springframework.web.util.UriComponentsBuilder.fromHttpUrl(UriComponentsBuilder.java:267) ~[spring-web-4.2.3.RELEASE.jar:4.2.3.RELEASE]
    at org.springframework.security.oauth2.client.filter.OAuth2ClientContextFilter.redirectUser(OAuth2ClientContextFilter.java:99) ~[spring-security-oauth2-2.0.8.RELEASE.jar:na]
    at org.springframework.security.oauth2.client.filter.OAuth2ClientContextFilter.doFilter(OAuth2ClientContextFilter.java:70) ~[spring-security-oauth2-2.0.8.RELEASE.jar:na]

Because URI is used as URL.

We should:

• support URI (or create a interceptor that allow user to customize the way to use the properties)
• or rename security.oauth2.client.userAuthorizationUri and security.oauth2.client.accessTokenUri as security.oauth2.client.userAuthorizationUrl and security.oauth2.client.accessTokenUrl

[kakawait]

If you think my point of view is correct I can create PR

[kakawait]

Today to avoid using hardcode/absolute hostname I have to do following modification:

• Rewrite OAuth2ClientContextFilter to support URI in favor to URL! By supporting URI you can now use relative path (supported by header Location and browser)

userAuthorizationUri: /uaa/oauth/authorize

• For accessTokenUri I just have a trick by setting following thing on Zuul

accessTokenUri: http://localhost:${server.port}/uaa/oauth/token

Thus Oauth2RestTemplate will use Zuul to call AuthorizationService. It could be better to add LoadBalancerd capability to Oauth2RestTemplate for replacing following tricks by

accessTokenUri: http://authorization-service/uaa/oauth/token

[dsyer]

I'm not sure we can handle any of the zuul or load balancer features here, so maybe you could move the discussion to spring-cloud/spring-cloud-security?

[kakawait]

@dsyer There is a way to transfer issue between project?

[dsyer]

No, but you can paste a link in the other project's issue and it will show up here automatically.

[dsyer]

Let's leave this one open to cover the changes you are asking for in OAuth2ClientContextFilter (to support relative URLs). The token endpoint would have to be covered in the client, so I don't think it makes sense here (but might in a Spring Cloud setting).

[kakawait]

But should I open an issue on spring-cloud/spring-cloud-security too? Maybe I will wait you completely finish analysis of https://github.com/kakawait/uaa-behind-zuul-sample before opening something new

[dsyer]

But should I open an issue on spring-cloud/spring-cloud-security too?

Yes, please, I think that's where the change would have to be made in Spring Cloud.

[jgrandja]

@dsyer Is there a change required here? Or is it just in Spring Cloud? Given that the discussion started with @EnableOauth2Sso.

[dsyer]

Yes, some change would be here since it relates to the client filter. (And @EnableOAuth2Sso is a Spring Boot feature now.)

[rwinch]

This might be resolved by using https://jira.spring.io/browse/SPR-13614

[hsjankie]

@dsyer Was the relative url change added yet, it would help a lot in our setup.

[dsyer]

There's no change here. If there was you would see the status updated.

[kakawait]

@hsjankie @jgrandja @dsyer I found a solution for accessTokenUri by simply enhance the used RestTemplate with Ribbon, please check here spring-attic/spring-cloud-security#61 (comment)

That was way more elegant than loopback trick that I experimented on my POC