# Auth tokens

## Creating a token

A signed-in member creates tokens under **account settings → API tokens**. The token value is displayed **once**, at creation. It is stored hashed; nobody, including an administrator, can read it back afterwards.

If a token is lost, revoke it and create a new one. There is no recovery path, by design.

## Using a token

```
Authorization: Bearer <token>
```

Send it over HTTPS only. A bearer token in a URL query string ends up in server logs, browser history and referrer headers — never put it there.

## Scope and identity

A token acts as the member who created it and carries that member's permissions — no more. A member token cannot reach administrative surfaces.

An endpoint that requires a permission the token's owner does not hold answers `403 forbidden_scope`.

## Revoking

Revoke a token from the same settings page. Revocation takes effect immediately.

Changing a password or an authentication version invalidates existing sessions; treat a suspected leak as a reason to revoke every token, not only the suspected one.

## Accounts that cannot authenticate

Editorial and system accounts cannot sign in, and cannot be used for API authentication either. Suspended and banned accounts are refused.

## Rate limits

Token authentication is rate limited like sign-in. Repeated failures are throttled, and identifiers are hashed before being stored.

## Operational advice

- One token per integration, so revoking one does not break the others.
- Name tokens after their consumer, not after the date.
- Rotate on staff changes.
- Never commit a token to a repository — treat a committed token as already public.
