PUT - registrationPut


Update the actual registration for a given client_id


[From RFC7592] To update a previously registered client’s registration with an authorization server, the client makes an HTTP PUT request to the client configuration endpoint with a content type of "application/json". The HTTP entity payload is a JSON [RFC7159] document consisting of a JSON object and all parameters as top-level members of that JSON object. This request is authenticated by the registration access token issued to the client. This request MUST include all client metadata fields as returned to the client from a previous registration, read, or update operation. The updated client metadata fields request MUST NOT include the "registration_access_token", "registration_client_uri", "client_secret_expires_at", or "client_id_issued_at" fields described in Section 3. Valid values of client metadata fields in this request MUST replace, not augment, the values previously associated with this client. Omitted fields MUST be treated as null or empty values by the server, indicating the client’s request to delete them from the client’s registration. The authorization server MAY ignore any null or empty value in the request just as any other value. The client MUST include its "client_id" field in the request, and it MUST be the same as its currently issued client identifier. If the client includes the "client_secret" field in the request, the value of this field MUST match the currently issued client secret for that client. The client MUST NOT be allowed to overwrite its existing client secret with its own chosen value. For all metadata fields, the authorization server MAY replace any invalid values with suitable default values, and it MUST return any such fields to the client in the response.


  • manageRegistration


clientId (required)
REQUIRED. OAuth 2.0 client identifier string. It SHOULD NOT be currently valid for any other registered client, though an authorization server MAY issue the same client identifier to multiple instances of a registered client at its discretion.
access (required)
Registration data updated by a given client.
Digest (required)
Digest of the body
Signature (required)
http-signature of the request (cf. https://datatracker.ietf.org/doc/draft-cavage-http-signatures/) The keyId must specify the way to get the relevant qualified certificate. It is requested that this identifier is - either an URL aiming to provide the relevant Qualified Certificate. - or the kid parameter retrieved through the certificate registration during a previous OAUTH2 Technical Setup
X-Request-ID (required)
Correlation header to be set in a request and retrieved in the relevant response

Return codes

200 Retrieval of the updated registration
400 Invalid status value
401 Unauthorized, authentication failure.
403 Forbidden, authentication successful but access to resource is not allowed.
405 Method Not Allowed.
406 Not Acceptable.
408 Request Timeout.
429 Too many requests.
500 Internal server error.
501 Not Implemented. This code should be used when the entry point is implemented but cannot provide a result, given the context. When the entry point is not implemented at all, HTTP400 will be returned.
503 Service unavailable.



Available authentification

OAuth 2.0