/
OPMetadataClientRegistration

OPMetadataClientRegistration

Overview

There are two general ways to register and manage OIDC "clients" (RPs), with metadata and dynamically. Metadata-based registration is analagous to the way CAS and SAML are supported in the IdP, through metadata resolution to files or online sources. It's not necessarily static since there are many ways of obtaining metadata (e.g., the process could be offloaded to some other system entirely but with output compatible with one of the supported formats).

A "native" JSON format is supported, as well as a profile of SAML metadata. The former is obviously more concise, but the latter is advantageous because it supports signing by third parties, and because of the myriad configuration features that rely on the use of SAML metadata, and its extensions, and for consistency with the rest of the supported protocols. There are also more advanced metadata loading options using the SAML format, such as the LocalDynamicMetadataProvider or DynamicHTTPMetadataProvider approaches.

For further information on configuring support for resolving this information, see OPClientResolution.

Avoiding Registration 3.1

As of V3.1, not every feature actually requires registration and management of clients. While the support for this with SAML or CAS is not heavily used, the IdP has always allowed for so-called “unverified” or (in very old versions, “anonymous”) relying party configuration, whereby profiles may be enabled for systems that are not found in metadata. This support is currently not universal within the OP feature set, but is expected to expand going forward because of the fact that OIDC and OAuth typically rely on back-channel communication to the OP with authentication methods that don’t necessarily require metadata.

Because of this additional authentication requirement, it may be desirable to operate (within an enterprise at least) with a more default profile configuration that extends to any clients issued credentials by some general management approach, such as service accounts managed within an IDM solution. Issuing service accounts may be more lightweight for many organizations than capturing details for creation of client metadata.

With V3.1, the following features are meant to operate successfully in the absence of client metadata, provided the relevant profiles are enabled for unverified relying party use:

These profiles all support client authentication, and this can be used in lieu of actually registering metadata for clients if desired.

As of V4.0, all the previously mentioned profiles but also OIDC.SSO and OIDC.UserInfo can be used with unverified relying party configuration, but all the request messages must meet the unregistered client policy.

JSON Format

Each RP is defined with a JSON structure that is defined by the OpenID Connect Dynamic Client Registration 1.0 specification. That is, the format is just the format of the messages in that protocol. The required fields are:

Name

Type

Description