Skip to main content
API-sleutels authenticeren verzoeken aan de /v1 Public API. Elke sleutel hoort bij een serviceaccount en wordt aangemaakt op de detailpagina van dat account in de Developer Hub. Gebruik een API-sleutel met beperkte scope voor een privé-backendintegratie wanneer het veilig opslaan en roteren van een geheim aan uw vereisten voldoet. Er is geen OAuth-client of tokenuitwisseling nodig. Raadpleeg Authenticatie als uw organisatie in plaats daarvan kortlevende OAuth-toegangstokens vereist.

​
Opbouw van een sleutel

  • Identificatie — begint met ak_. Veilig om te vermelden in tickets, logs en configuratie; op zichzelf verleent deze geen toegang.
  • Geheim — begint met lsk_live_. Dit is de inloggegevens die uw integratie presenteert. Het wordt eenmalig getoond, bij het aanmaken of roteren, en kan daarna niet meer worden opgehaald. De sleutellijst toont alleen de laatste vier tekens (bijvoorbeeld lsk_live_…xQc4), zodat u een rij kunt koppelen aan de inloggegevens die een aanroeper bezit.
  • Machtigingen — een subset van de machtigingen van het bijbehorende serviceaccount, gekozen bij het aanmaken. Een sleutel kan nooit meer dan het account toestaat.
  • Vervaldatum — verplicht. Elke sleutel heeft een vervaldatum.
Sla geheimen op in een secret manager zodra ze worden getoond. Leg ze nooit vast in versiebeheer, sluit ze niet in in clientcode en deel ze niet via chat. Iedereen die over het geheim beschikt, kan handelen met de machtigingen van de sleutel.

​
Een sleutel aanmaken

Maak op de detailpagina van het serviceaccount een sleutel aan in vier stappen: geef de sleutel een naam, kies de machtigingen die deze specifieke sleutel nodig heeft, kies een vervaldatum — 30, 90 of 365 dagen, of een aangepaste periode van maximaal een jaar — en controleer. Het geheim wordt na afronding eenmalig weergegeven. Beperk elke sleutel tot de smalste set machtigingen die de aanroeper nodig heeft, ook wanneer het account meer toestaat. Als een sleutel uitlekt, bepalen de machtigingen ervan de omvang van de schade.

​
Roteren zonder downtime

Bij rotatie wordt een nieuw geheim uitgegeven en start een overlapperiode — 1 uur, 24 uur of 7 dagen — waarin het oude geheim blijft werken. Zo kunt u het nieuwe geheim in uw eigen tempo doorvoeren in uw implementaties:
1

De sleutel roteren

Kies een overlapperiode die uw traagste implementatiepad dekt. Het nieuwe geheim wordt eenmalig getoond — sla het direct op.
2

Uw integraties bijwerken

Vervang het oude geheim overal waar het is geconfigureerd. De status van de sleutel wordt weergegeven als in overlap totdat de periode afloopt.
3

Controleren voordat de periode afloopt

Gebruik de requestlogs om te bevestigen dat het verkeer is overgegaan naar het nieuwe geheim. Wanneer de overlap eindigt, kan het oude geheim niet meer worden gebruikt voor authenticatie.
Roteer ook vóór de vervaldatum: sleutels die hun vervaldatum naderen, worden in de sleutellijst gemarkeerd als bijna verlopen. Een verlopen sleutel kan niet meer worden gebruikt voor authenticatie — verzoeken die ermee worden gedaan, geven een 401 terug met code credential_expired.

​
Direct herroepen

Herroeping gaat onmiddellijk in en is permanent — er is geen overlapperiode en geen mogelijkheid tot ongedaan maken. Herroep een sleutel zodra u vermoedt dat het geheim is blootgesteld; roteer in plaats daarvan wanneer u een correcte inloggegevens vervangt. Verzoeken die met een herroepen sleutel worden gedaan, geven een 401 terug met code credential_revoked. Als u alle sleutels van een integratie in één keer wilt stoppen, schakel dan in plaats daarvan het bijbehorende serviceaccount uit.