Great, thanks a lot!

Added responseModes configuration setting to OAuth2AuthorizationProfileConfiguration and DefaultOIDCAuthorizationConfiguration.

Also wired property idp.oauth2.responseModes to OIDC.SSO in oidc-config., defaulting to empty string. Empty value means that all supported response modes are allowed.

Good point. I do have quite a few configuration properties directly wired to the RP (some are RP-specific and only show through its interface, but some could be reused by the OP and are in a parent interface). Going forward the RP should not do that, with the OP taking priority (adding global properties) if needed.

The SAML stuff tended not to use those global properties in the wiring, but if we need to start allowing for that, maybe we should have a standard convention for the “priority” of those properties relative to each other so it’s consistent.

In practice, at least for now, it’s simplest for a deployer to just use a dedicated RP override for the upstream OP because in most cases, there’s only going to be one of them anyway.

The OAuth2AuthorizationProfileConfiguration (inherited by OIDCAuthorizationConfiguration) already contains responseMode configuration property. It’s there for RP-plugin’s purposes to define the response_mode parameter for its authorization requests. One option would be to use this for OP’s purposes too, but the problem is that the RP’s configuration property idp.authn.oidc.rp.client.responseMode is wired to OIDC.SSO in our oidc-config module, and thus any value set to that property would make default OP’s OIDC.SSO requiring that response mode.

After discussing with , we agreed it makes sense to add a new responseModes property for OP’s purposes. Its default value should probably contain the all values referred in OIDC spec (query, fragment and form-post).