RFC 7592 — OAuth 2.0 Dynamic Client Registration Management
Spec: datatracker.ietf.org/doc/html/rfc7592Status: Full
RFC 7592 extends RFC 7591 with endpoints for a client to read, update, and delete its own registration using a Registration Access Token (RAT).
Implemented
- Read —
GET /oidc/register/{client_id}returns the current client metadata. - Update —
PUT /oidc/register/{client_id}replaces the client metadata document, subject to any constraints carried over from the original Initial Access Token. - Delete —
DELETE /oidc/register/{client_id}soft-deletes the client. Subsequent token requests at/oauth/tokenfor thatclient_idare rejected as if the client did not exist; the registration record is preserved for audit. - RAT authentication — every management request must present the Registration Access Token returned at registration time as
Authorization: Bearer <rat>. - IAT constraint immutability — fields that were constrained by the original IAT (allowed grant types, redirect URI patterns, scopes) cannot be widened on update.
- Error responses — missing or invalid RATs yield
401/403with the standard RFC 7592 error bodies.
End-user "connected apps"
Clients created via IAT-gated DCR carry an owner_user_id referencing the consenting user. This powers a self-service "connected apps" listing:
GET /api/v2/users/{user_id}/connected-clients
Authorization: Bearer <mgmt-api-token with read:clients|read:users>The response is a slim projection of each client (no secrets, no internal config) — client_id, name, logo_uri, registration_type, registration_metadata (e.g. domain, integration_type), and timestamps. Soft-deleted clients are excluded so the listing always reflects live, revocable connections.
A revocation flow is just DELETE /oidc/register/{client_id} from the user's UI (proxying through your application server, which holds the RAT).