Godkendelse

API-nøgler (anbefales til integrationer)

En API-nøgle er et personligt adgangstoken, der er knyttet til et medlem af din konto.

Opret en under Indstillinger → Plugins → RolChat API-nøgler. Hemmeligheden vises én gang; derefter er kun de første ti tegn synlige, og RolChat gemmer kun en SHA-256-hash.
Format: rcp_ efterfulgt af 32 tilfældige bytes i base64url, cirka 45 tegn i alt. Præfikset gør en nøgle genkendelig i logs og adskiller den fra et sessionstoken.
Omfang (scopes): vælges fra et fast katalog af kapabiliteter, når nøglen oprettes. En nøgle kan aldrig gøre mere end det medlem, der oprettede den: ved hvert kald kontrolleres begge betingelser, kapabiliteten er i nøglens scopes og medlemmet har den stadig. Indsnævr medlemmets rolle, og nøglen indsnævres med den.
Levetid: nøgler udløber ikke af sig selv. Tilbagekald en nøgle fra profilsiden eller med DELETE /api/v1/tokens/:id; tilbagekaldelsen træder i kraft med det samme. Der findes ingen rotation på stedet: tilbagekald, og opret en ny nøgle.
Oprettelse og tilbagekaldelse skrives til revisionsloggen.

Send den som et bearer-token - der er ingen separat header til API-nøgler:

curl https://api.rolchat.com/api/v1/contacts?limit=20 \
  -H "Authorization: Bearer rcp_…" \
  -H "X-Account-Id: 7c1d2c6e-…"

Anmodninger med en plugin-API-nøgle er begrænset til 300 pr. minut.

JWT-sessioner

Webappen og mobil-SDK’erne logger ind med e-mail og adgangskode (eller Google eller Apple) og modtager et tokenpar.

Token	Levetid	Bemærkninger
Adgangstoken	15 minutter	RS256, verificeres mod JWKS på `/.well-known/jwks.json`
Opdateringstoken	30 dage	Roteres ved hver opdatering; genbrug af et roteret token tilbagekalder hele kæden

Claims: sub (bruger), acc (konto), rl (rolle) og, for roller pr. websted, sts (tilladte websteder).

POST /auth/login, /auth/refresh, /auth/swap-company og /auth/logout er de eneste endpoints i godkendelsesflowet, der ikke må have headeren X-Account-Id, som beskrives herunder.

Headeren `X-Account-Id`

Hver godkendt anmodning, bortset fra de fire ovenfor, skal angive den konto, den handler på:

X-Account-Id: <account uuid>

Serveren kontrollerer, at headeren er lig med tokenets acc-claim (eller API-nøglens konto). En manglende header giver 400 missing_required_header; en uoverensstemmelse giver 403 account_context_mismatch. Headeren findes, så en klientfejl eller et genafspillet token aldrig ubemærket kan læse en anden lejers data: uoverensstemmelsen afvises, før nogen forespørgsel køres, og hver loglinje kan henføres til en konto uden at afkode tokenet.

Brugere i flere virksomheder

Én person kan tilhøre flere virksomheder. Hver virksomhed har sit eget token (sit eget acc-claim). Sådan skifter du:

POST /api/v1/auth/swap-company
Authorization: Bearer <current access token>

{ "account_id": "<target uuid>" }

Målet skal være en af kalderens available_companies (returneres ved login), ellers 403 forbidden. Svaret er et nyt par af adgangs- og opdateringstoken for målet; det gamle opdateringstoken tilbagekaldes, og der skrives en revisionshændelse auth.account.swapped.

Multifaktorgodkendelse

TOTP-baseret MFA kan aktiveres pr. medlem og kræves pr. konto. Når den er slået til, returnerer POST /auth/login en udfordring, og sessionen fuldføres med POST /auth/mfa/verify. Backupkoder udstedes ved aktiveringen.

Loginruter er begrænset til 10 forsøg pr. IP pr. minut og 5 pr. e-mail pr. 15 minutter.
Ti mislykkede login låser e-mailen i 30 minutter; svaret indeholder code: account_locked.
reCAPTCHA kan slås til pr. handling (tilmelding, login, nulstilling af adgangskode); den offentlige opstartskonfiguration leveres fra GET /api/v1/captcha.