OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens & OAuth 2.1

[sebastianGit]

Are there plans to support "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens" - see: https://tools.ietf.org/html/rfc8705?

Overall, it would be great if there was something like a public roadmap for CF UAA, to allow users of UAA to understand how and whether it is planned to follow the more recent enhancements of OAuth (see https://tools.ietf.org/html/draft-ietf-oauth-v2-1-00, which provides a consolidated view on many of the topics that have been published in the context of OAuth).

If there is a public roadmap, it would be great, if you could provide a link.

[cf-gitbot]

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

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

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

[strehle]

There is no roadmap, but I know about UAA forks which provides this already - so if you have also forked it , just create a PR

[strehle]

close this now because I dont see any progress , but more relevant is, that this solution for CF might be difficult, because UAA itself is not getting the mTLS request. We have always a go router or haproxy in between and thus UAA can only check of existance of a Header which is protected by the router in between.

What UAA can do is the check of private key jwt authentication which replaces the secrets. This will be added soon, because I will work on it.

1st , added this into OIDC proxy , which is direction of UAA as client towards other OIDC servers, e.g. Microsoft Azure AD, Okta or SAP IAS -> https://github.com/cloudfoundry/uaa/issues/1933 2st provide this mechanism for clients in UAA.