Add support for Dynamic Client Registration (#346)

Implements full OpenID Connect Dynamic Client Registration 1.0 + RFC 7591/7592 support for v7, validated against the OpenID conformance suite.

### Features

**Registration endpoint (RFC 7591 / OIDC DCR 1.0)**
- Client Registration Endpoint (`POST`) — register clients dynamically with the OP assigning `client_id`, `client_secret`, and a Registration Access Token (RAT).
- Configurable access control: open registration or Initial Access Token mode.
- Optional "register, then approve" — config option to create dynamically registered clients **disabled** until an administrator reviews and enables them.
- Configurable default scope set assigned when a registration omits `scope`.

**Client Configuration Endpoint (RFC 7592)**
- Read (`GET`), Update (`PUT`, full-replace semantics) and Delete (`DELETE`) of a registered client, authenticated by the Registration Access Token.
- RAT is stored only as a hash; the plaintext is returned once and **rotated** on each read/update (RFC 7592 §3 requires `registration_access_token` + `registration_client_uri` in the response).
- Uniform `401` on every auth failure so the endpoint never reveals whether a client exists.

**Metadata validation & enforcement**
- Strict validation of client-supplied metadata: `redirect_uris`, informational URIs (`logo_uri`/`client_uri`/`policy_uri`/`tos_uri`), `contacts`, `application_type`, `request_uris`, `subject_type`, `default_max_age`, `require_auth_time`, `default_acr_values`, `initiate_login_uri`, `software_id`/`software_version`.
- `redirect_uris` constrained by `application_type` (native → custom-scheme/loopback only; web+implicit → https, non-localhost) and rejected if they contain a fragment (incl. empty trailing `#`).
- `grant_types` / `response_types` / `token_endpoint_auth_method` rejected when outside the OP's supported sets (single source of truth shared by discovery, validator, and admin form).
- `response_type` ↔ `grant_type` correspondence enforced (auto-normalized on registration, live-adjusted in the admin UI).
- `default_acr_values` restricted to the OP's advertised `acr_values_supported`.
- Unsupported features (encrypted/signed UserInfo & ID Tokens, pairwise `sector_identifier_uri`, front-channel logout, etc.) are rejected rather than silently ignored.
- Impersonation protection (OIDC DCR §9.1) — protected informational URIs must share a host with a registered redirect URI.
- Admin-only properties (e.g. `authproc`) are scrubbed from registration input and preserved across DCR updates.
- `Content-Type: application/json` enforced on register/update requests.

**Client model & admin UI**
- Per-client metadata is presence-based and stored as the single source of truth (getters return the stored value; spec defaults applied at registration time).
- `is_confidential` kept in lockstep with `token_endpoint_auth_method` / `application_type`, on both registration and admin save.
- Admin form gains all client metadata fields (logo/client/policy/tos URIs, contacts, application type), a multiselect `default_acr_values` bound to supported values, and live JS for response/grant-type correspondence and public/confidential client type.

**Discovery**
- OP metadata now advertises the supported `response_types`, `grant_types`, and `token_endpoint_auth_methods` (including `none`).

**Docs**
- Supported-specs list, configuration reference, and the v6→7 upgrade guide updated, including new config options, client properties, and transition guidance for existing/pre-DCR clients.

Author: cicnavi

.github/workflows/test.yaml

@@ -266,6 +266,13 @@ jobs:
       - name: Run form_post implicit tests
         run: |
           ./conformance-suite/scripts/run-test-plan.py  "oidcc-formpost-implicit-certification-test-plan[server_metadata=discovery][client_registration=static_client]" ./main/conformance-tests/conformance-implicit-ci.json
+      - name: Run Dynamic registration conformance tests
+        # The only remaining non-passing tests are two OP-wide gaps (signed UserInfo
+        # and signing-key rotation), which are recorded as expected failures in
+        # conformance-tests/dynamic-warnings.json, so this step is a blocking gate.
+        # See docs/5-oidc-conformance.md for the inventory.
+        run: |
+          ./conformance-suite/scripts/run-test-plan.py  --expected-failures-file ./main/conformance-tests/dynamic-warnings.json --expected-skips-file ./main/conformance-tests/dynamic-skips.json "oidcc-dynamic-certification-test-plan[response_type=code]" ./main/conformance-tests/conformance-dynamic-ci.json
       - name: Stop SSP
         working-directory: ./main
         run: |

composer.json

@@ -31,7 +31,7 @@
         "psr/container": "^2.0",
         "psr/log": "^3",
         "simplesamlphp/composer-module-installer": "^1.3",
-        "simplesamlphp/openid": "~v0.3.5",
+        "simplesamlphp/openid": "~0.3.8",
         "spomky-labs/base64url": "^2.0",
         "symfony/expression-language": "^7.4",
         "symfony/psr-http-message-bridge": "^7.4",

config/module_oidc.php.dist

@@ -448,6 +448,24 @@ $config = [
      */
     ModuleConfig::OPTION_PROTOCOL_DISCOVERY_SHOW_CLAIMS_SUPPORTED => false,
 
+    /**
+     * Guzzle HTTP client options for the protocol-layer outbound requests made by the underlying `openid`
+     * library, such as fetching a client's 'jwks_uri' or a 'request_uri'. The array is passed through verbatim
+     * to the Guzzle client; see https://docs.guzzlephp.org/en/stable/request-options.html for the full list.
+     *
+     * Leave empty (the default) to use the library's secure defaults (TLS verification enabled). The typical
+     * use for a non-empty value is testing against endpoints that present self-signed certificates (for
+     * example, the OpenID conformance suite), by disabling TLS verification:
+     *
+     *     ModuleConfig::OPTION_PROTOCOL_HTTP_CLIENT_OPTIONS => [
+     *         'verify' => false,
+     *     ],
+     *
+     * SECURITY WARNING: disabling TLS verification ('verify' => false) exposes these fetches to
+     * man-in-the-middle attacks. Only use it in development/testing, NEVER in production.
+     */
+    ModuleConfig::OPTION_PROTOCOL_HTTP_CLIENT_OPTIONS => [],
+
     /**
      * Settings regarding Authentication Processing Filters.
      * Note: An OIDC authN state array will not contain all the keys which are
@@ -570,6 +588,136 @@ $config = [
      */
     ModuleConfig::OPTION_ADMIN_UI_PAGINATION_ITEMS_PER_PAGE => 20,
 
+    /***************************************************************************
+     * (optional) OpenID Connect Dynamic Client Registration (DCR) related
+     * options. If not enabled (the default), Dynamic Client Registration
+     * capabilities will be disabled.
+     **************************************************************************/
+
+    /**
+     * Enable or disable OpenID Connect Dynamic Client Registration (DCR), as
+     * described in the OpenID Connect Dynamic Client Registration 1.0
+     * specification (which is also compatible with RFC 7591). Default is
+     * disabled (false).
+     *
+     * When enabled, the module serves:
+     * - a Client Registration Endpoint (HTTP POST to .../oidc/register) which
+     *   creates a new client from the supplied client metadata and returns its
+     *   client_id, client_secret (for confidential clients), a
+     *   registration_access_token and a registration_client_uri; and
+     * - a Client Configuration Endpoint (HTTP GET to
+     *   .../oidc/register?client_id=...) which returns the current client
+     *   registration when called with the registration_access_token as an HTTP
+     *   Bearer token.
+     *
+     * When enabled, the registration endpoint is also advertised as the
+     * 'registration_endpoint' claim in the OP discovery metadata.
+     *
+     * Note that dynamically registered clients are stored like any other client
+     * and are visible / manageable in the admin UI.
+     */
+    ModuleConfig::OPTION_DCR_ENABLED => false,
+
+    /**
+     * Access-control mode for the registration (create) endpoint. Only relevant
+     * if Dynamic Client Registration is enabled. Possible values:
+     *
+     * - DcrRegistrationAuthEnum::Open (the default): open registration, meaning
+     *   anyone may register a client without authenticating. In this mode you
+     *   should protect the endpoint from abuse using rate limiting at the
+     *   web-server level.
+     * - DcrRegistrationAuthEnum::InitialAccessToken: callers must present a
+     *   valid Initial Access Token (provisioned out-of-band) as an HTTP Bearer
+     *   token to register. The accepted tokens are configured using
+     *   the OPTION_DCR_INITIAL_ACCESS_TOKENS option below.
+     */
+    ModuleConfig::OPTION_DCR_REGISTRATION_AUTH =>
+        \SimpleSAML\Module\oidc\Codebooks\DcrRegistrationAuthEnum::Open->value,
+
+    /**
+     * Allowlist of Initial Access Tokens (opaque, randomly generated strings)
+     * accepted by the registration endpoint. This option is only consulted when
+     * the access mode (OPTION_DCR_REGISTRATION_AUTH) is set to
+     * DcrRegistrationAuthEnum::InitialAccessToken; in 'open' mode it is ignored.
+     *
+     * A registration request must then carry one of these tokens as an HTTP
+     * Bearer token. Use long, high-entropy values and treat them as secrets.
+     *
+     * Format: string[] (array of strings)
+     */
+    ModuleConfig::OPTION_DCR_INITIAL_ACCESS_TOKENS => [
+//        'a-long-random-secret-token',
+    ],
+
+    /**
+     * Enable or disable impersonation protection for Dynamic Client
+     * Registration, as recommended by Section 9.1 of the OpenID Connect Dynamic
+     * Client Registration 1.0 specification. Default is enabled (true).
+     *
+     * When enabled, the host component of the logo_uri, policy_uri and tos_uri
+     * client metadata values (if provided) must match the host of one of the
+     * registered redirect_uris. Otherwise, the registration is rejected with an
+     * 'invalid_client_metadata' error. This mitigates a rogue client trying to
+     * impersonate a legitimate one by reusing its branding (logo) or links.
+     *
+     * You may want to disable this (set to false) if your clients legitimately
+     * host these resources on a different domain than their redirect URIs (for
+     * example, on a shared CDN or marketing domain). Note that the client_uri
+     * (the client home page) is intentionally NOT subject to this check.
+     */
+    ModuleConfig::OPTION_DCR_IMPERSONATION_PROTECTION_ENABLED => true,
+
+    /**
+     * Default scopes assigned to a Dynamic Client Registration (DCR) client that
+     * registers WITHOUT an explicit 'scope'. The OpenID Connect Dynamic Client
+     * Registration 1.0 specification makes 'scope' OPTIONAL and lets the OP
+     * assign a default set; this option controls that set.
+     *
+     * If this option is omitted (commented out), it defaults to ALL scopes this
+     * OP supports, so a scope-less dynamic client may request any supported scope
+     * (including 'offline_access', i.e. refresh tokens). To restrict what a
+     * scope-less dynamic client receives, set an explicit list below; only values
+     * that are actually supported by this OP are kept.
+     *
+     * This applies ONLY to Dynamic registrations. Manual (admin) and OpenID
+     * Federation automatic registrations are NOT affected: a federated client
+     * with no 'scope' in its metadata still defaults to 'openid' only.
+     *
+     * Note: an explicit but unsupported 'scope' in a registration request is NOT
+     * treated as "not specified" - the unsupported values are dropped and the
+     * client ends up with 'openid' only (it does not receive this default set).
+     *
+     * Format: string[] (array of scope names)
+     */
+//    ModuleConfig::OPTION_DCR_DEFAULT_SCOPES => [
+//        'openid',
+//        'offline_access',
+//    ],
+
+    /**
+     * Whether a client registered through Dynamic Client Registration (DCR) is
+     * created ENABLED and therefore immediately usable.
+     *
+     * When true (default), a dynamically registered client can be used right
+     * away. Set to false to create such clients DISABLED, so an administrator
+     * must review and enable them in the admin UI before they can complete
+     * authorization / token flows ("register, then approve"). While disabled, the
+     * client can still read and manage its own registration (RFC 7592) using the
+     * registration access token it received - it simply cannot obtain tokens until
+     * an administrator enables it.
+     *
+     * Note: there is no standard way to signal "pending approval" back to the
+     * client in the registration response (it receives a normal success response),
+     * so you may need to communicate the review step out-of-band.
+     *
+     * This applies ONLY to Dynamic registrations. OpenID Federation automatic
+     * registrations are always created enabled (they are vouched for by their
+     * trust chain).
+     *
+     * Format: bool (default: true)
+     */
+    ModuleConfig::OPTION_DCR_REGISTERED_CLIENTS_ENABLED => true,
+
     /***************************************************************************
      * (optional) OpenID Federation-related options. If these are not set,
      * OpenID Federation capabilities will be disabled.