Dynamic client registration addresses the scalability and flexibility limits of static OAuth client onboarding. Instead of prearranging client identifiers and secrets out of band for each authorization server and every instance of a client, the dynamic approach lets software introduce itself at runtime and receive a unique client_id (and often a client_secret). This is essential when the same client needs to talk to many providers of a standardized API, when countless instances of a native or desktop app must safely authenticate, or in ecosystems like email where clients and servers are highly decentralized. Importantly, registration alone does not grant access: resource-owner consent is still required, while authorization servers can use policy controls (for example, trusted “whitelists,” blocked “blacklists,” and default “graylists”) to balance interoperability and security.
The core protocol (RFC 7591) is a simple POST to a registration endpoint with JSON client metadata such as display name, redirect_uris, grant_types, and desired scopes. The authorization server validates and may override inputs, then issues the client_id, optionally a client_secret, indicates how the client must authenticate at the token endpoint, and records timestamps and expirations. Client metadata comes in two forms: values the client requests and the authoritative values the server registers and returns. Human-facing fields can be internationalized with language-tagged variants, and stronger assurance can be achieved with software statements: signed JWTs carrying pre-vetted metadata from a trusted issuer. When present and verified, these statements let servers lock down sensitive attributes, improve trust in self-asserted data, and logically group client instances that share the same software identity.
Lifecycle management (RFC 7592) complements initial registration by providing a dedicated configuration endpoint and a registration access token. With these, a client can read (GET) its current registration, update (PUT) metadata such as names, redirect URIs, or scopes, and delete (DELETE) its registration when it is no longer needed. Servers can rotate client secrets, constrain dynamically registered clients (for example, limit scopes or grant types), validate consistency between grant_types and response_types, and revoke issued tokens on deletion. In practice, the pattern enables clients to self-register per authorization server, persist and manage their credentials over time, and achieve large-scale interoperability without sacrificing the core OAuth security model or administrator policy controls.
Information passed in dynamic registration
The authorization server’s approval page, showing a randomized client ID and the requested client display name
The authorization server showing several registered clients
The client homepage showing a dynamically registered client ID and controls to manage the registration
FAQ
What problem does dynamic client registration solve compared to static registration?It removes the need to pre-provision client IDs/secrets out of band for every client–server pairing. This lets a client obtain credentials at runtime from any compliant authorization server and allows each instance of an app (for example, native/mobile copies) to get its own client_id and, when appropriate, its own client_secret. It scales better for ecosystems with many providers or many client instances (for example, email, OpenID Connect, SCIM).How does the core dynamic registration flow work?The client sends an HTTP POST with JSON metadata (for example, redirect_uris, grant_types, client_name) to the server’s registration endpoint. The authorization server validates the request, assigns a new client_id and usually a client_secret, may normalize/augment fields (for example, token_endpoint_auth_method, response_types), and returns a 201 Created with the registered metadata. The client stores the returned values for subsequent OAuth calls.Can a client choose its own client_id or client_secret during registration?No. The client_id and client_secret are always issued by the authorization server to avoid collisions, impersonation, or weak secrets. A client may propose other metadata, but the authorization server has the final say and can override or reject requested values.Which metadata fields are commonly used and what do they control?Examples include:
- redirect_uris: Allowed redirect targets for front-channel flows.
- grant_types and response_types: Grants and corresponding authorization endpoint responses the client will use (for example, authorization_code with code; implicit with token).
- token_endpoint_auth_method: How the client authenticates at the token endpoint (none, client_secret_basic, client_secret_post, client_secret_jwt, private_key_jwt).
- client_name, client_uri, logo_uri, tos_uri, policy_uri: User-facing info.
- scope: Space-separated scopes the client may request.
- contacts: Admin/owner contact points.
- jwks_uri or jwks: Where/how to obtain the client’s public keys.
- software_id and software_version: Identify the software across instances.After registering, how does a client read, update, or delete its registration?Per RFC 7592, the registration response includes:
- registration_client_uri: A client-specific management endpoint.
- registration_access_token: A bearer token to call that endpoint.
With these, the client can:
- GET to read current metadata.
- PUT with the full metadata document to update (omit fields like client_id_issued_at, client_secret_expires_at, registration_client_uri, registration_access_token; the server may rotate secrets).
- DELETE to unregister; the server should remove the client and revoke its tokens.Does registration automatically grant access to protected resources?No. Registration only introduces the client to the authorization server. Access still requires the resource owner’s authorization. Servers can use whitelists (pre-trusted clients with streamlined consent), blacklists (disallowed attributes such as bad redirect URIs), and a graylist (default path where users decide) to balance security and UX for dynamically registered clients.What are software statements and when should I use them?A software statement is a signed JWT from a trusted authority containing client metadata (for example, client_name, client_uri, logo_uri, software_id/version). The client includes it in registration (software_statement). The server validates the signature and treats those claims as authoritative, overriding self-asserted values. Use them to lock down stable attributes, increase trust across multiple authorization servers, and enable admin actions across all instances of the same software.How should multi-instance or native apps handle client secrets?Each instance should register and obtain its own client_id and, if it can safely store one, its own client_secret. Reusing a single secret across all installs is insecure. If a client cannot safely keep a secret, it should register as a public client (no client authentication at the token endpoint), accepting the trade-offs, while the server may limit scopes or grant types for such clients.How does internationalization of user-facing metadata work?Provide a default field (for example, client_name) and locale-specific variants by appending “#” to the field name (for example, client_name#fr). The authorization server selects the most specific value for the user’s locale, falling back to the generic field if needed.What validation and policy checks should a registration endpoint perform?Typical checks include:
- Validate token_endpoint_auth_method against allowed methods.
- Ensure grant_types and response_types are consistent and supported.
- Require and validate at least one redirect_uri (and optionally enforce block/allow lists).
- Constrain scopes for dynamically registered clients.
- Ignore or filter unknown fields; reject malformed metadata.
- Optionally require an OAuth token to call the registration endpoint, tying registrations to an authenticated party.
These controls improve security without blocking interoperability.
pro $24.99 per month
access to all Manning books, MEAPs, liveVideos, liveProjects, and audiobooks!
OAuth 2 in Action ebook for free
