skip to content

After RFC 7591 dynamic client registration succeeds, what comes back, and how is that registration changed afterwards?

level: seniorimportance: should knowfreq 33%

answer

  1. POST metadata, get a record back
  2. 201 with the values actually applied
  3. zero means no expiry
  4. a second token, for the record only
  5. PUT replaces, it does not merge

basics

~20 s

The registration endpoint answers HTTP 201 with the client metadata it actually applied, a client_id and client_id_issued_at, usually a client_secret with client_secret_expires_at, and for servers supporting RFC 7592 a registration_access_token plus a registration_client_uri for later reads, updates and deletion.

solid answer

~40 s

A client POSTs its metadata as JSON to the `registration_endpoint` the authorization server advertises — `redirect_uris`, `grant_types`, `token_endpoint_auth_method`, optionally `software_id` and a `software_statement`. The endpoint may be open or may require an initial access token. Success is **HTTP 201** carrying the metadata **as the server applied it**, plus `client_id` and `client_id_issued_at`; if the method needs one, a `client_secret` and `client_secret_expires_at`, where `0` means it does not expire. Where the server implements RFC 7592, the response also carries a `registration_access_token` and a `registration_client_uri`: the client reads, replaces or deletes its own registration there with that token — which manages the client record and is not an access token for any resource server. Failures are **400** with `invalid_redirect_uri` or `invalid_client_metadata`.

code

http · 11 lines
http
POST /register HTTP/1.1
Host: as.example.net
Content-Type: application/json
Authorization: Bearer ey...initial-access-token

{
  "redirect_uris": ["https://filings.broker.example.com/callback"],
  "grant_types": ["authorization_code", "refresh_token"],
  "token_endpoint_auth_method": "client_secret_basic",
  "software_id": "4NRB1-0XZABZI9E6-5SM3R"
}

go deeper

for a junior

Recall the shape: a client can ask for a client_id by POSTing its metadata, and the authorization server answers with the identifier and, when the chosen method needs one, a secret.

for a middle

Explain the response fields and what each is for, that the applied metadata may differ from what was requested, and that the registration_access_token manages the record rather than calling any API.

for a senior

Show the operational traps: a full-replacement PUT that strips a redirection URI, an expiry date nobody monitors, a stranded record after a lost management token, and a protected endpoint gated by an initial access token.

for a principal

The question you own is whether registrations should be issued dynamically at all in a given estate: automated onboarding against a client population nobody can attribute, and what evidence you want attached to each record before it exists.

## The request Dynamic registration lets software obtain a `client_id` by asking, instead of by a human filling in a console form. The client POSTs a JSON document of **client metadata** to the `registration_endpoint`, which the authorization server publishes in its metadata document. Typical members: - `redirect_uris` — where authorization responses may be delivered; - `grant_types` — which flows this client will use; - `token_endpoint_auth_method` — how it will authenticate, defaulting to `client_secret_basic` when omitted; - `software_id` — a stable identifier for *the software*, the same across every deployment of it; - `software_statement` — the same kind of metadata, signed as a JWT by whoever publishes the software. The endpoint may be **open** — anyone may register — or **protected**, requiring an *initial access token*: a credential obtained out of band and presented on the registration request, which is how an operator keeps the endpoint from being a free client factory. ## What comes back A successful registration answers **HTTP 201** with a JSON document: | Field | Meaning | |---|---| | `client_id` | the identifier issued for **this registration** | | `client_id_issued_at` | when it was issued | | `client_secret` | present only when the chosen authentication method needs one | | `client_secret_expires_at` | when that secret stops working; `0` means it does not expire | | `registration_access_token` | RFC 7592: the credential for managing this registration | | `registration_client_uri` | RFC 7592: where to manage it | | the metadata members | the values **the server actually applied** | The last row is the one that catches people. The server may modify, replace or ignore what was requested — narrowing `grant_types`, substituting a different `token_endpoint_auth_method`, adjusting values it does not support. The client must use what came back, not what it sent, and a client that stores its own request as the source of truth will fail later in ways that look unrelated. Failures are **400** with a JSON error: `invalid_redirect_uri` when one of the supplied redirection URIs is unacceptable, and `invalid_client_metadata` when some other submitted value is invalid or unsupported. ## Managing the registration afterwards RFC 7592 defines the management half, and a server may implement registration without it. Where it is offered, the `registration_client_uri` is a per-client resource and the `registration_access_token` is the credential for it: 1. **GET** returns the current registration. 2. **PUT** replaces it. This is a full replacement, not a merge — a member omitted from the body is *removed*, which is how a client that sends a partial update quietly loses a redirection URI it still needs. 3. **DELETE** deregisters the client, after which its `client_id` is no longer usable. Say which token you mean when discussing this. A `registration_access_token` manages a client record and is worthless at a resource server; an access token obtained through a grant is worthless at the registration resource. Conflating them is the classic error here. ## `software_id` versus `client_id`, and the software statement These answer different questions. `software_id` identifies *the program* and stays the same across every instance and deployment of it. `client_id` identifies *one registration* — one installation, one deployment, one tenant. A hundred deployments of the same software therefore share one `software_id` and hold a hundred distinct `client_id` values, which is exactly what lets an operator revoke one of them without touching the rest. A `software_statement` is a JWT of client metadata signed by an issuer the authorization server trusts. It lets a publisher assert values the registering instance should not be free to choose — which redirection URIs belong to this software, for instance. RFC 7591 is explicit about precedence: where a member appears both in the software statement and in the plain JSON of the request, **the software statement's value takes precedence**. ## Operational consequences worth stating - **`client_secret_expires_at` is a deadline nobody sees.** A non-zero value means the integration stops on a date, and the only warning is in a registration response stored months earlier. - **A lost `registration_access_token` is a stranded registration.** The client can still authenticate at the token endpoint but can no longer read, update or delete its own record. - **An open registration endpoint is a capacity and hygiene question**, which is why initial access tokens exist; the alternative is a store of client records nobody can attribute.

  • A client sends a PUT to its registration_client_uri containing only the one member it wanted to change. What happens?
    Everything else in the registration is removed. RFC 7592's update is a full replacement of the client's metadata, so the body must carry the complete intended registration. A partial body typically strips `redirect_uris` or `grant_types`, and the breakage appears at the next authorization request rather than at the update.
  • The same software is deployed by forty different brokers. What differs between those deployments, and what does not?
    Each deployment registers separately and holds its own `client_id`, credential and `registration_access_token`, so one can be revoked without touching the others. The `software_id` is the same across all forty, because it identifies the program rather than any one installation.
  • What does an initial access token do that the registration_access_token does not?
    An initial access token authorises *creating* a registration at a protected registration endpoint, before any client record exists. The `registration_access_token` is issued *by* that registration and authorises reading, replacing or deleting that one record afterwards. Neither is usable at a resource server.

saying these in an interview costs you the question

  • Uses the registration_access_token to call a resource server
  • Stores the requested metadata instead of what the server returned
  • Reads client_secret_expires_at of 0 as already expired
  • Sends a partial PUT expecting a merge of the registration
  • Treats software_id as a per-deployment identifier
  • Lets the plain JSON override a signed software statement