Issuer URL is reported wrong in /.well-known/openid-configuration

[c4milo]

What version of UAA are you running?

4.11.0

How are you deploying the UAA?

I am deploying the UAA

• locally only using gradlew

What did you do?

curl http://localhost:8080/uaa/.well-known/openid-configuration | jq .

What did you expect to see? What goal are you trying to achieve with the UAA?

I expect to see issuer with value http://localhost:8080/uaa since that's what I have set in my uaa.yml file

What did you see instead?

It wrongly returns http://localhost:8080/uaa/oauth/token as issuer

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/156793074

The labels on this github issue will be updated when the story is started.

[jhamon]

Can you confirm the name of the property you are setting in uaa.yml?

[jhamon]

Right now it seems like the way this has been implemented is to always append /oauth/token to the configured issuer url. This is consistent with the value we put into the iss claim of the JWT tokens authored by the UAA.

Is this causing a problem for you or did you just find the behavior surprising?

[c4milo]

@jhamon, the issuer I have configured is http://localhost:8080/uaa, the behavior is surprising given that we are driving the value from the IdP configuration and there is a parameter to declare the token URL already. It is also inconsistent with what very well known OpenIDConnect providers use, see for instance:

• https://accounts.google.com/.well-known/openid-configuration
• https://auth0.com/docs/protocols/oidc/openid-connect-discovery
• https://connect2id.com/products/server/docs/api/discovery
• https://docs.pingidentity.com/bundle/pf_sm_pingfederateOauth20Endpoints_pf84/page/concept/openIdConnectMetadataEndpoint.html

[c4milo]

It is also important to bear in mind that the issuer URL is often used by client libraries as base URL to reach out for .well-known/openid-configuration

[c4milo]

Another detail I noticed is that most of the URLs aren't taking the configured issuer URL as base URL:

[vincentserpoul]

I will also add here the specs of openid itself: https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig

[devopsmica]

Weill that be corrected?

[Ianwww]

@c4milo Were you able find a solution or workaround?

[c4milo]

@Ianwww, nop. I had to tell my client library to skip discovery and provided the individual URLs to it.

[mbalsam82]

Is there any chance that this issue will be scheduled anytime soon?

• It's uncommon to have the token endpoint as the issuer claim of an access token (or in the oidc discovery response) - see previous comments.
• It's not even correct for all cases (e.g. implicit flow)
• It's simply confusing that the config.issuer for an identity zone is not what ends up in the iss claim, especially since this behavior is not mentioned in the API docs. It requires to inspect the code to figure this out.
• Usage with JWT/OIDC libraries can be problematic (see above)
• As /oauth/token is hardcoded in UaaTokenUtils AND used to build the discovery response, you're forced to expose the token endpoint at this path, if you still want discovery to work and don't want to transform the response in your gateway/proxy.

It's still the same behavior in v74.13.0

[toedter]

A workaround is not to call https://<your UAA>/.well-known/openid-configuration but https://<your UAA>/oauth/token/.well-known/openid-configuration

Then the issuer still looks strange but is correct in terms of OIDC.

Unfortunately CORS is not configured properly for https://<your UAA>/oauth/token/.well-known/openid-configuration