Auth_list_public_idps
curl -X GET "https://example.com/auth/idps?slug=string"{ "idps": [ { "cognito_provider_name": "string", "domains": [ "string" ], "id": "string", "name": "string", "protocol": "string" } ]}Auth_get_config GET
Previous Page
`POST /auth/logout` — expire the session cookies, and revoke the session row when the caller could be authenticated. POST
# ⚠️ It runs for a caller who cannot authenticate, and that is the fix An `HttpOnly` cookie can only be cleared by the server, so a sign-out gated on a live session is a sign-out that fails exactly when it is needed. With `SelfAuthContext` the extractor refused first and the handler never ran, so four cases left the browser holding a **refresh** token after a deliberate sign-out: an expired access cookie, an already-revoked session (the second call of an idempotent logout), an api-key caller, and a token with no `origin_jti`. [`MaybeSelfAuth`] collapses all four into one shape. **The `None` arm has authenticated nobody.** It may only do what is safe for an anonymous caller — clearing cookies is (the browser is discarding its own state), revoking a server-side session is not, and that is why the revoke hangs off `Some`. Not a forced-logout primitive: `rh-cl95c`'s CSRF layer refuses a state-changing request the browser reports as cross-site, and it keys on `Sec-Fetch-Site` rather than on a session cookie precisely so it still fires on the routes that run without one — this being the first of them. (A cookie-gated check would not have: `SameSite=Strict` withholds the cookie on the very cross-site POST being defended against.)