Page Comparison

As with user authentication, it is possible to apply normalization or matching rules to the “client_id” supplied by the OAuth client. From an OAuth perspective, the client_id is still officially whatever the client uses, but this can be separated from the manner in which authentication happens, on a per-validator basis.

Unlike with user authentication, there are no global transform or matching settings defined, but each validator individually supports them as defined in the javadocs. For example (in conf/authn/oauth2client-authn-config.xml):

<util:list id="shibboleth.authn.OAuth2Client.Validators">
    <ref bean="shibboleth.OIDCClientInfoValidator" />
    <ref bean="shibboleth.JWTValidator" />
    <bean parent="shibboleth.LDAPValidator" p:matchExpression="^\S+\.\d+$" />
</util:list>

While in some cases it may be acceptable to reuse the existing post-login subject canonicalization configuration used for username handling, it is expected that this may not work for most deployments. You may set the property idp.authn.OAuth2Client.c14n.postLoginFlows to an alternate bean ID referencing a list defined in conf/c14n/subject-c14n.xml that defines the c14n flow(s) to run separately from the built-in list. In many cases, an example bean such as this may suffice:

    <!-- Separate list of flows to apply to OAuth2 client authentication. -->
    <util:list id="custom.OAuth2Client.PostLoginSubjectCanonicalizationFlows">
        <ref bean="c14n/simple" />
    </util:list>