STANDARD
Dynamic Client Registration (RFC 7591/7592) — Primer
Dynamic Client Registration (RFC 7591/7592) standardizes how OAuth clients register and later manage their metadata via a protected endpoint.
Why it matters
Standards reduce risk and vendor lock‑in. We implement this spec across our Studios and runtime so policy is portable.
Where it’s enforced
- Gateway: pre‑execution gating (plan/schema pins, params/egress)
- Shield: inline budgets/stream caps/content checks
- PDP: decisions with constraints/obligations/TTL
- IdP: passports, token exchange, consent/DPoP
How it works (high level)
RFC 7591/7592 specify dynamic registration and management. Clients POST metadata (optionally with a software_statement) to /register, receive client_id (and secret) plus a registration_access_token and registration_client_uri for subsequent GET/PATCH/DELETE (7592).
POST /register
{
"redirect_uris": ["https://app.example.com/cb"],
"grant_types": ["authorization_code"],
"response_types": ["code"],
"token_endpoint_auth_method": "tls_client_auth",
"software_statement": "eyJ..."
}mermaid
sequenceDiagram
participant Client
participant AS as Authorization Server
Client->>AS: POST /register (metadata)
AS-->>Client: 201 { client_id[, client_secret] }
Client->>AS: (7592) GET/PATCH/DELETE /register/{client_id}