After discussion with , refactored the bean-injection to the map of serializers and the list of deserializers. This way we make sure that the beans that get injected are prototypes. That may not always be required, but the message handlers may be stateful.

The beans are injected via two factories (new global beans):

• shibboleth.oidc.RefreshTokenSerializerFactory

• shibboleth.oidc.RefreshTokenDeserializerFactory

Those can be adjusted with two constructor parameters:

• id: the id for the bean to be wired

• allowNonPrototype: whether to allow non-prototype beans, defaults to false. The factory will return null if this is false but the injected bean is not prototype.

Added two new beans that are wired to the actions dealing with refresh tokens:

shibboleth.oidc.DefaultRefreshTokenSerializationStrategies (in token beans)

• Map of serialization strategies (keyed with the refresh token type)

• Serializer: BiFunction<ProfileRequestContext,RefreshTokenClaimsSet,String>

• Custom map can be wired via idp.oauth2.refreshToken.serializationStrategies -property

shibboleth.oidc.DefaultRefreshTokenDeserializers (in abstract beans)

• List of deserializers

• Deserializer: BiFunction<ProfileRequestContext,String,RefreshTokenClaimsSet>

• Used by token, introspection and revocation flow

• Custom list can be wired via idp.oauth2.refreshToken.deserializers -property

I drafted a prototype on this by modifying SetRefreshTokenToResponseContext action to be wired with refreshTokenSerializationStrategies: (Map<String, BiFunction<ProfileRequestContext,RefreshTokenClaimsSet,String>>). The key refers to the refresh token type (a new profile configuration option) and value to the bi-function that encodes the given RefreshTokenClaimsSet into a String that’s sent to back to the RP in the token endpoint.

The example bi-function for producing JWT refresh tokens seems to be fairly simple to implement by exploiting PopulateJWTSignatureSigningParametersHandler for building the SecurityParametersContext with SignatureSigningParameters, which is fed to the JWSTokenSigner for signing.

The deserialisation of incoming refresh tokens could be configured in a similar way: with a map of Strings (refresh token types) to (bi-)functions. That would need to be wired to ValidateGrant action (that validates the refresh token grant in the token endpoint) and for AbstractProcessTokenAction to provide compatibility with the introspection and revocation endpoints.