Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 26133:2024 OpenID Connect Dynamic Client Registration 1.0 — Automated Client Onboarding
How OpenID Connect Relying Parties dynamically register with OpenID Providers to obtain client credentials
1. Dynamic Client Registration Overview
ISO/IEC 26133:2024 defines OpenID Connect Dynamic Client Registration 1.0, which specifies how an OpenID Connect Relying Party (RP) can dynamically register with an OpenID Provider (OP). The RP provides information about itself to the OP and obtains the credentials needed to interact with it, including an OAuth 2.0 Client ID.
Before an RP can use OpenID Connect services, it must establish a relationship with the OP. Dynamic registration automates this process, eliminating the need for manual, out-of-band registration for each client application. This is particularly valuable in ecosystems where many clients need to interact with many providers.
Dynamic registration is what enables the “Login with Google/Facebook/Apple” experience. Each of these providers implements OpenID Connect Dynamic Client Registration to accept new client applications without manual intervention.
2. Client Metadata Schema
During registration, the RP presents its metadata to the OP. The following table describes key metadata fields:
| Metadata Field | Required | Description |
|---|---|---|
redirect_uris |
Yes | Array of redirection URI values for the client |
response_types |
Optional | Array of OAuth 2.0 response type values (default: code) |
grant_types |
Optional | Array of OAuth 2.0 grant type values |
application_type |
Optional | web or native to indicate client type |
client_name |
Optional | Human-readable name of the client |
logo_uri |
Optional | URL for the client’s logo |
token_endpoint_auth_method |
Optional | Authentication method for the Token Endpoint |
contacts |
Optional | Array of email addresses for client administrators |
sector_identifier_uri |
Optional | URL for pairwise identifier validation |
The
redirect_uris field is the only REQUIRED metadata field — and for good reason. Incorrect redirect URI validation is the most common source of OAuth 2.0 security vulnerabilities. Every registered redirect URI must be an exact match target for authorization responses.3. Registration and Configuration Endpoints
The standard defines two primary endpoints for client registration management:
Client Registration Endpoint: This is an OAuth 2.0 protected resource through which a client can be registered at an Authorization Server. The RP sends a JSON document containing its metadata, and the OP responds with a Client Information Response containing the registered client’s identifier and additional metadata.
Client Configuration Endpoint: Once registered, clients can manage their registration information through this endpoint. The endpoint URL is returned by the OP in the initial registration response. Clients use a Registration Access Token to authenticate when accessing their configuration.
| Operation | HTTP Method | Endpoint | Description |
|---|---|---|---|
| Register | POST | Registration Endpoint | Create a new client registration |
| Read | GET | Configuration Endpoint | Retrieve current registration |
| Update | PUT | Configuration Endpoint | Modify client configuration |
| Delete | DELETE | Configuration Endpoint | Remove client registration |
4. Security Considerations and Best Practices
Dynamic client registration introduces unique security considerations. Important engineering practices include:
- Initial Access Tokens: The OP may issue initial access tokens that grant access to the registration endpoint. This prevents anonymous registration and provides a trust mechanism.
- Sector Identifier Validation: For pairwise subject identifiers, the
sector_identifier_uriallows the RP to host a file containing its set of redirect URIs. The OP fetches this file to validate that all registered redirect URIs belong to the same entity. - Stateless Registration: In stateless (or “software statement”) mode, the OP can derive registration information from a signed JWT without maintaining per-client state, which is useful for highly scalable deployments.
Native application clients face unique risks: if a native client embeds a client secret, that secret can be extracted through reverse engineering. Native apps relying on dynamic registration should use PKCE and avoid hardcoded secrets. The Registration Access Token should be treated as sensitive data.
Frequently Asked Questions
Q: What is the difference between stateless and stateful dynamic registration?
A: In stateful registration, the OP stores client metadata and returns a client ID referencing that stored state. In stateless registration (using software statements), all client metadata is encoded in a signed JWT, allowing the OP to derive client information without persistent storage. Stateless registration scales more easily but limits the ability to update registration after initial creation.
Q: Can I update my client registration after initial creation?
A: Yes. The Client Configuration Endpoint supports read, update, and delete operations. You use the Registration Access Token returned during initial registration to authenticate these operations. If you lose the Registration Access Token, you may need to re-register.
Q: What happens if the OP rejects my registration request?
A: The OP returns a registration error response with appropriate error codes. Common reasons include invalid redirect URI format, unsupported metadata fields, or missing required fields. The standard defines specific error codes to help diagnose the issue.
Q: How does dynamic registration work with native mobile apps?
A: Native apps can use dynamic registration like web apps, but with important caveats. The client secret (if issued) cannot be securely stored on the device. The recommended approach is to use the Authorization Code Flow with PKCE and avoid reliance on client secrets. Some OPs also issue application_type: native-specific redirect URIs like custom schemes or loopback interface redirects.
