PUBLIC
Ends the caller's session. Tolerant by design — any caller (valid
token, expired token, no cookie at all) gets a 204 with
Set-Cookie headers clearing the session cookies. The endpoint
is unauthenticated for that reason: requiring a valid JWT to
log out would leave clients with stale tokens unable to clean
up their browser state.
When a refresh_token cookie is presented, the server revokes
it at Cognito (best-effort — a revocation failure does not
block the cookie clear). Without a refresh cookie, only the
client-side cookies are cleared; the access token is then
useful only until its natural expiry (≤ 60 min by default).
The endpoint has no request body. Idempotent: repeat calls
return the same 204 + cookie clear.
| Time | Status | User Agent | |
|---|---|---|---|
Retrieving recent requests… | |||
Why this endpoint exists — and why it is unauthenticated
Logging out has to work when the session is already broken. That is the normal case: the customer's token expired hours ago and they now click "sign out".
If this endpoint demanded a valid JWT, a client holding a stale token could not clean up its own browser state — the cookies would stay, and the customer would appear signed in while every call failed. So it is unauthenticated on purpose.
Every caller gets 204. Valid token, expired token, no cookie at all: same response, with Set-Cookie headers clearing the session either way.
Request
curl -X POST https://api.acc.funtrips.io/v2/auth/logout \
--cookie "refresh_token=eyJjdHki…"From a browser:
await fetch(`${BASE}/auth/logout`, { method: 'POST', credentials: 'include' });No body, no headers. credentials: 'include' matters — without it the cookies are not sent, and the server cannot revoke the refresh token.
Response
204 No Content, with cookie-clearing headers:
Set-Cookie: access_token=; Max-Age=0; HttpOnly; Secure; SameSite=None; Path=/
Set-Cookie: refresh_token=; Max-Age=0; HttpOnly; Secure; SameSite=None; Path=/One header per cookie, with attributes matching how they were set — which is what makes the browser actually drop them.
What actually gets revoked
This is the part worth understanding, because "logged out" is not instant.
With a refresh_token cookie present: the refresh token is revoked at the identity provider, so the session cannot be extended. Revocation is best-effort — a failure does not block the cookie clear, on the grounds that a customer who clicked "sign out" should always end up with a cleared browser.
Without a refresh cookie: only the cookies are cleared. Nothing is revoked server-side.
Either way, the access token stays technically valid until it expires naturally — up to 60 minutes. It is a signed JWT; nothing consults a revocation list on each request.
Logout clears the client, it does not instantly kill the credential.For most storefronts that is fine. If your threat model needs harder guarantees — a shared kiosk, a public terminal — do not rely on this endpoint alone. Discard your in-memory copies of the tokens, and treat the ≤60-minute access-token window as the real exposure.
Idempotent
Repeat calls return the same 204 with the same cookie clear. Safe to call on every "sign out" click, on app teardown, and defensively when your client detects an unrecoverable session.
Errors
| Status | Meaning |
|---|---|
204 | Session cleared — the only success, and the normal answer to almost anything |
500 | Unexpected fault. Retryable, though the cookies were probably already cleared |
There is no 401 and no 404. A logout that "fails" because the session was already gone is not a failure.
Notes
- Native apps should call this to revoke the refresh token, then delete their stored copies. The cookie headers are irrelevant to them; the revocation is not.
- After logout, refresh returns
401withrefresh-token-invalid— which is the expected, correct outcome.