Autentisering

API-nycklar (rekommenderas för integrationer)

En API-nyckel är en personlig åtkomsttoken som är knuten till en medlem i ditt konto.

• Skapa en under Inställningar → Plugins → RolChat API-nycklar. Hemligheten visas en gång; därefter syns bara dess tio första tecken, och RolChat lagrar bara en SHA-256-hash.
• Format: rcp_ följt av 32 slumpmässiga byte i base64url, totalt cirka 45 tecken. Prefixet gör att en nyckel går att känna igen i loggar och skiljer den från en sessionstoken.
• Behörighetsomfång: väljs ur en fast katalog av funktioner när nyckeln skapas. En nyckel kan aldrig göra mer än den medlem som skapade den: vid varje anrop kontrolleras båda villkoren, funktionen finns i nyckelns omfång och medlemmen har den fortfarande. Begränsa medlemmens roll så begränsas nyckeln med den.
• Livslängd: nycklar upphör inte att gälla av sig själva. Återkalla en nyckel från profilsidan eller med DELETE /api/v1/tokens/:id; återkallelsen gäller omedelbart. Det finns ingen rotation på plats: återkalla och skapa en ny nyckel.
• Skapande och återkallelse skrivs till granskningsloggen.

Skicka den som en bearer-token - det finns ingen separat header för API-nyckeln:

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

Förfrågningar med en API-nyckel för plugin är begränsade till 300 per minut.

JWT-sessioner

Webbappen och mobil-SDK:erna loggar in med e-post och lösenord (eller Google eller Apple) och får ett tokenpar.

Token	Livslängd	Anmärkningar
Åtkomsttoken	15 minuter	RS256, verifieras mot JWKS på /.well-known/jwks.json
Förnyelsetoken	30 dagar	Roteras vid varje förnyelse; återanvändning av en roterad token återkallar hela kedjan

Claims: sub (användare), acc (konto), rl (roll) och, för roller per webbplats, sts (tillåtna webbplatser).

POST /auth/login, /auth/refresh, /auth/swap-company och /auth/logout är de enda endpoints i autentiseringsflödet som inte får skicka headern X-Account-Id som beskrivs härnäst.

Headern X-Account-Id

Varje autentiserad förfrågan utom de fyra ovan måste ange vilket konto den agerar i:

X-Account-Id: <account uuid>

Servern kontrollerar att headern är lika med tokenens claim acc (eller API-nyckelns konto). En saknad header ger 400 missing_required_header; en avvikelse ger 403 account_context_mismatch. Headern finns för att en bugg i klienten eller en återuppspelad token aldrig ska kunna läsa en annan kunds data i tysthet: avvikelsen avvisas innan någon fråga körs, och varje loggrad kan knytas till ett konto utan att tokenen avkodas.

Användare i flera företag

En person kan tillhöra flera företag. Varje företag har sin egen token (sitt eget claim acc). För att byta:

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

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

Målet måste vara ett av anroparens available_companies (returneras vid inloggning), annars 403 forbidden. Svaret är ett nytt par åtkomst- och förnyelsetoken med målet som omfång; den gamla förnyelsetokenen återkallas och en granskningshändelse auth.account.swapped skrivs.

Flerfaktorsautentisering

TOTP-baserad MFA kan aktiveras per medlem och krävas per konto. När den är på returnerar POST /auth/login en utmaning och sessionen slutförs med POST /auth/mfa/verify. Reservkoder utfärdas vid aktiveringen.

Skydd vid inloggning

• Inloggningsvägar är begränsade till 10 försök per IP-adress och minut och 5 per e-postadress per 15 minuter.
• Tio misslyckade inloggningar låser e-postadressen i 30 minuter; svaret innehåller code: account_locked.
• reCAPTCHA kan aktiveras per åtgärd (registrering, inloggning, återställning av lösenord); den publika startkonfigurationen levereras från GET /api/v1/captcha.