Logging out invalidates the supplied refresh token so it can never be used to obtain new token pairs. The operation is designed to be idempotent: the service records the revocation on the first call and silently acknowledges any subsequent calls with the same token, which means client-side retry logic is safe to implement without risking unexpected error responses.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/ricardomb-tech/auth-service/llms.txt
Use this file to discover all available pages before exploring further.
POST /auth/logout
Authentication: None required — the refresh token itself identifies the session to terminate.Request Body
The opaque refresh token associated with the session to be terminated. Must not be blank.
Response — 204 No Content
The response has no body. A204 indicates the refresh token has been revoked (or was already revoked).
Error Responses
| Status | Condition |
|---|---|
400 Bad Request | The refreshToken field is missing or blank. Returns application/problem+json. |
curl Example
Idempotency: Calling this endpoint with a refresh token that has already been revoked — or that was never valid — still returns
204 No Content. There is no error condition for “token not found”. This makes logout safe to retry unconditionally, which simplifies client implementations that need to guarantee a clean logout even under flaky network conditions.The access token is not invalidated. Because JWT access tokens are stateless and validated cryptographically, the service cannot revoke them on demand. An access token that was issued before logout remains valid until it naturally expires — which is at most 15 minutes from the time it was issued. For security-sensitive scenarios (e.g. account compromise), ensure that downstream services re-validate the token’s issue time or implement short TTLs. Rotating the JWT signing secret (
JWT_SECRET_CURRENT) is the nuclear option that invalidates all outstanding access tokens.