Additional attributes for ClientRegistration and ProviderDetails

[philsttr]

New Behavior

I'd like the ability to attach additional attributes/properties to ClientRegistrations and ProviderDetails, so that it can be utilized by ReactiveOAuth2AccessTokenResponseClients and OAuth2AccessTokenResponseClients when requesting tokens.

For example, when configuring ClientRegistrations or Providers via spring-boot auto configuration, I'd like the ability to do something like this:

spring:
  security:
    oauth2:
      client:
        provider:
          my-provider:
            issuer-uri: https://my-issuer
            # New Feature: Custom Attributes
            attributes:
              my-custom-provider-attribute: my-custom-provider-attribute-value
        registration:
          my-client:
            provider: my-provider
            client-id: my-client-id
            client-secret: my-client-secret
            client-authentication-method: basic
            authorization-grant-type: client_credentials
            scope:
              - my.scope.1
              - my.scope.2
            # New Feature: Custom Attributes
            attributes:
              my-custom-registration-attribute: my-custom-registration-attribute-value

And ClientRegistration and ProviderDetails would each have an additional Map<String, Object> attributes property.

Current Behavior

ClientRegistrations and ProviderDetails only support the standard set of attributes/metadata/properties that are utilized by the standard ReactiveOAuth2AccessTokenResponseClients and OAuth2AccessTokenResponseClients

Context

We're utilizing an OAuth 2.0 Authorization Server that supports some additional, non-standard, inputs when requesting tokens. One example is that it supports an input parameter that determines the type of token to return... opaque token or JWT.

In order to support this input, I currently customize the WebClient used by ReactiveOAuth2AccessTokenResponseClient with a custom filter that adds the additional form inputs statically, applying the same values for every request for all client registrations. I'd like for the filter to be able to inspect additional attributes/properties defined on each ClientRegistration or ProviderDetails in order to determine what inputs to add. I know I could create a separate, parallel, set of configuration properties for each client registration and provider, but that gets pretty messy from a configuration property standpoint, and from a spring-boot auto-configuration standpoint. Having first-class support for custom attributes on the client registrations and providers would simplify configuration, and be more intuitive.

[jgrandja]

Hey @philsttr. A way to store custom attributes does seem valuable.

Can you provide a couple more examples so I can better understand the type of attributes you need to store.

I'm wondering if you can leverage the existing ClientRegistration.ProviderDetails.configurationMetadata and we can add ClientRegistration.configurationMetadata, which will be needed when we implement OIDC Dynamic Client Registration.

[philsttr]

The main use case is for specifying the token type/format... "opaque" or "jwt" for now, but possibly others in the future. Ideally this attribute could be specified at the provider OR client registration level, with the client registration level value taking precedence (when examined by our customized WebClient filter).

A smaller specialized use case is for retrieving a token with all scopes available to the client, without having to enumerate all the scopes to request in the client registration. We know this is not ideal, and are trying to get rid of this specialized use case, but we still need to support it for now. This is currently just a boolean value.

Regarding utilizing configurationMetadata... This sounds like a good approach, but some changes would be needed before we can use it. Specifically, we're using openid, and the ProviderDetails.configurationMetadata is currently populated from the openid .well-known/openid-configuration endpoint, without the possibility to add to it (unless I missed something). So, the ability to add to the metadata returned by the .well-known/openid-configuration endpoint would be needed before we could utilize it.

In total, the following modifications would be needed:

1. Allow to add additional properties to ProviderDetails.configurationMetadata (in addition to the metadata returned by the .well-known/openid-configuration endpoint)
2. Create ClientRegistration.configurationMetadata, and allow adding properties to it.

[jgrandja]

@philsttr I agree with the 2 changes you mentioned.

We should also account for the use case where ClientRegistration.configurationMetadata could be updated without the use of Dynamic Client Registration, as well, ClientRegistration.ProviderDetails.configurationMetadata could also be updated without the use of Provider Configuration discovery.

Would you be interested in submitting a PR for this? FYI, there is no rush as this won't be able to go into 5.5.

[philsttr]

Another engineer on my team, @eurythmia, would like to work on this and submit a PR. Might be a while before we can get to it though.

[jgrandja]

No worries @philsttr. There is no rush for this. I have it scheduled for 5.6.0-M1, which is at least 2-3 months out.