...
Notably, this implementation supports “unverified” clients and/or resource servers; that is, it is optional to require client metadata (and thus some form of static or dynamic registration) for either party. This deployment decision is represented by the choice to enable the OAUTH2.Token and OAUTH2.TokenAudience profile configuration beans within the shibboleth.UnverifiedRelyingParty bean in relying-party.xml. Not doing so will disallow the request of if the client or “primary” resource server are not registered. This does not preclude tailoring specific behavior to registered clients or resource servers because when metadata is available, the active profile configuration must come from a different, matching “verified” relying party configuration.
...