The client identifier is stored on the RP profile config, and can be overridden for > 1 OP by RP overrides.

The storage service has been removed, and replaced by a simple injected Map.

As per , we can remove the storage service and just inject the map directly into the strategy.

As pointed out, having another resolver service for this was unnecessary, instead, adding the logic via a strategy to the profile configuration (which is already a reloadable service). This is now done using the following logic:

• By default, the client identifier lookup strategy constructs a client_id value from that provided in the oidc properties file. This allows quick configuration if there is only a single client.

• If there is more than one client e.g. some kind of discovery flow is used to choose the OP, the client_id property value can be commented out, and the strategy will use a further embedded strategy to lookup the client identifier from the given issuer_id of the chosen OP.

  • The default strategy for this is backed by a storage service. Currently, an in-memory service is constructed from the same map as shown in . This would need to be added to the relying party XML by the deployer.

• This can also be overridden by specifying a client_id in a RelyingPartyOverrides profile bean for an OP. This is arguably better than having to add the map into the relying-party.xml. Although it would mean adding an override for every OP if you are dealing with more than one.

As with the client authentication resolver, a single mapping could be taken from the properties file for easier configuration.