Support custom CAs in oauth login

[gbaso]

Expected Behavior

The internal rest clients should trust custom CAs.

Current Behavior

The internal clients only support CAs in the jdk truststore.

Context

In corporate environments sometime the identity provider is part of the corporate network and has an HTTPS certificate that is signed by the corporate CA.

Applications with oauth/oidc login perform several requests to the IdP, for retrieving metadata or for exchanging tokens. This is done with internal clients, for example in ClientRegistrations or in AbstractRestClientOAuth2AccessTokenResponseClient, that are not configurable. While the latter allows to replace the RestClient, at the cost of having to reconfigure the message converters and status handler, the former does not.

The only avenue then is to add your custom CAs to the jdk truststore, usually done with the ca-certificates buildpack. Unfortunately, loading CAs at runtime doesn't seem to work in native image.

It would be useful to be able to specify ssl bundles when configuring registrations via properties, and for those bundles to be applied to the internal clients.

[lbruun]

Similar issue encountered.

When the OAuth2 Authorization server is using a custom CA you really need to jump through an incredible amount of hoops.

I believe what is often missed is the fact that in a high-security environment we cannot just add CAs at the JVM level. In such an environment a CA is often only applicable for a specific outbound http connection, it must not apply to any outbound http connection that the application makes.

Another issue encountered is the fact the an application may interact with several OAuth2 Authorization Servers. And the same argument again: a given CA applies to a specific one. Not any outbound connection to an OAuth2 Authorization Server.

What we have

Discovery or provider's config/metadata

Spring Security has a feature whereby you only need to specify the Authorization Server's issuer-url. From this Spring Security can discover the rest of the information it needs to know. This will not work if the endpoint uses a custom CA because the http client used to retrieve the metadata information is non-configurable.

Customize the http client (RestTemplate / RestClient)

The docs at Customize the RestOperations used by OAuth2 Client Components provides some guidance on how to customize the RestTemplate/RestClient used to interact with the Authorization Server. Note that those docs refer to deprecated classes as of v.6.4. This aside, the recipe provided still falls short as it will apply to any OAuth2 Provider used in the application, not a specific one.

Ideal solution?

To fulfill requirements that the truststore configuration must be as targeted as possible, one can imagine that it would be possible to specify trust material on a per-provider basis, as in the following:

spring:
  security:
    oauth2:
      client:
        registration:
          my-oidc-client-a:
            provider: my-oidc-provider-a
            client-id: my-client-id-a
            ...
          my-oidc-client-b:
            provider: my-oidc-provider-b
            client-id: my-client-id-b
            ...
        provider:
          my-oidc-provider-a:
            issuer-uri: https://my-oidc-provider-a.com
            ssl-bundle: my-bundle-a
            ...
          my-oidc-provider-b:
            issuer-uri: https://my-oidc-provider-b.com
            ssl-bundle: my-bundle-b
            ...

Only problem with the above proposal is that it uses a construct from Spring Boot, namely SslBundle. It is unfortunate that the SslBundle sits in Spring Boot and not Spring Framework as it would be ideal for this purpose. Perhaps there are other - and better - solutions?