Removing a client registration

Deleting a registration

All domains, identifiers, and tokens in these examples are fictional. The pipeline sends DELETE to the client's configuration endpoint, with the registration access token it received when it registered the client:

DELETE /register/review-482-b17f HTTP/1.1
Host: auth.photos.example
Authorization: Bearer demo-registration-access-token-482

HTTP/1.1 204 No Content
Cache-Control: no-store
Pragma: no-cache

204 No Content confirms that the client has been removed. Its client ID, client secret, and registration access token are now all invalid, and the photo service will refuse review-482-b17f at both the authorization endpoint and the token endpoint.

Other answers mean something different. 405 means the server does not support deletion through this endpoint, so the client has to be removed some other way. 401 means the token is not valid or the client does not exist. For a pipeline cleaning up, a 401 for a client it created usually means the client is already gone, which is the outcome it wanted, though it is worth logging. 403 means this client is not allowed to delete itself.

Once the client is gone, the pipeline deletes its own copies of the client secret and the registration access token.

What happens to issued tokens

Deleting a client does not automatically reach everything the client was given. RFC 7592 says the authorization server should, where possible, immediately invalidate every authorization grant, access token, refresh token, and other token associated with the client. How far that reaches depends on where each token is checked:

• Refresh tokens and unused authorization codes are presented to the authorization server, which knows the client is gone. They stop working.
• Reference access tokens that the photo API checks through introspection stop working as soon as the authorization server reports them inactive.
• Self-contained JWT access tokens that the photo API validates locally keep working until they expire, as Token revocation described. The API has no reason to ask about a token whose signature and claims check out.

So deleting a client ends its access within the lifetime of its longest-lived access token, not instantly. Short access token lifetimes keep that window small, and an API protecting something sensitive can use introspection instead of trusting a JWT until it expires.

The grants people approved end as well. If someone had connected a test photo account to review site 482, the connection would disappear from that account's list of connected applications, because the application it named no longer exists.

Registrations nobody deletes

The pipeline deletes its clients because it knows when a site goes away. An app on a phone rarely gets that chance. Uninstalling an app normally gives it no opportunity to run code, so it cannot send a DELETE. An installation that is reset or reinstalled simply registers again, and its old client stays behind with a client ID and registration access token that nothing will ever use.

An authorization server that accepts dynamic registrations therefore needs its own cleanup. It can expire registrations that have not been used for a long time, invalidating their registration access tokens at the same moment, and its operators can remove a client that abuses the service. A client can discover that it was removed: an invalid_client error at the token endpoint, or a 401 at its configuration endpoint, tells it to register again, after which people approve it again.

Three ways access ends

Deleting a registration is the broadest of three actions that end a client's access, and they are easy to mix up:

Each one leaves self-contained access tokens usable until they expire. What differs is what survives: revocation leaves the client registered, a disconnection leaves the client but not your grant, and deletion leaves nothing at all.