Hoe API-Sleutels Worden Opgeslagen (En Wat Te Doen Als Je Er Een Kwijtraakt)

Als je een developer-API-sleutel bent kwijtgeraakt, is het directe antwoord: er is geen manier om deze terug te halen, en support kan hem ook niet voor je herstellen, omdat de daadwerkelijke sleutelwaarde nergens wordt opgeslagen na het moment van aanmaken. De enige oplossing is de oude sleutel intrekken en een nieuwe genereren. Hier is precies waarom dat zo is en wat er in plaats daarvan daadwerkelijk aan de serverkant wordt opgeslagen.

Wat Er Gebeurt Op Het Moment Dat Je Een Sleutel Genereert

Wanneer je een nieuwe API-sleutel aanmaakt, genereert het systeem een willekeurige sleutelwaarde, met een voorvoegsel zodat deze in één oogopslag herkenbaar is als een API-sleutel, opgebouwd uit cryptografisch willekeurige bytes in plaats van iets voorspelbaars. Die rauwe sleutel wordt je precies één keer getoond, in het antwoord op het aanmaakverzoek, met een expliciete opmerking om deze nu te kopiëren omdat hij niet opnieuw wordt getoond. Voordat deze ergens wordt opgeslagen, laat het systeem hem door een eenrichtingshash lopen en slaat het alleen die hash op — de rauwe sleutel zelf wordt nooit in de database geschreven, nooit gelogd, en nooit op een manier bewaard die later kan worden opgehaald, door jou of door iemand met servertoegang.

Waarom Een Eenrichtingshash in Plaats van Gewoon de Sleutel Opslaan

Een eenrichtingshash is zo ontworpen dat je kunt verifiëren of een waarde overeenkomt zonder het proces om te kunnen keren en de oorspronkelijke invoer te herstellen. Wanneer je een API-verzoek doet, hasht het systeem de sleutel die je stuurt en vergelijkt die hash met wat is opgeslagen — als ze overeenkomen, wordt het verzoek geauthenticeerd. Dit betekent dat zelfs bij een volledige databasecompromissie een aanvaller een lijst met hashes krijgt, geen bruikbare API-sleutels; ze kunnen een hash niet omkeren naar de oorspronkelijke sleutelwaarde, dus je daadwerkelijke inloggegevens blijven beschermd, zelfs als de opslaglaag zelf wordt blootgesteld.

Dit is dezelfde reden waarom de sleutel je maar één keer wordt getoond. Als het systeem hem je later opnieuw zou kunnen tonen, zou dat betekenen dat hij ergens in opslag herstelbaar was, wat het hele punt van het hashen ervan om zeep zou helpen.

Wat Daadwerkelijk Zichtbaar Is in Je Dashboard

Je lijst met API-sleutels toont de naam die je elke sleutel hebt gegeven, wie deze heeft aangemaakt, en wanneer deze is aangemaakt en voor het laatst bijgewerkt — bewust niet de sleutelwaarde zelf, aangezien die nooit is bewaard. Dit is genoeg informatie om te identificeren welke sleutel welke is (nuttig als je er meerdere hebt uitgegeven voor verschillende integraties) en om te zien wanneer een sleutel is gemaakt, zonder enig risico dat de waarde via het dashboard zelf lekt.

Als Je Een Sleutel Kwijtraakt

Omdat de rauwe waarde daadwerkelijk nergens meer bestaat na het aanmaakantwoord, is het kwijtraken ervan geen support-ticket — het is per ontwerp niet herstelbaar. De juiste actie is de kwijtgeraakte sleutel intrekken (wat het record volledig verwijdert, waardoor alles wat deze gebruikt onmiddellijk ongeldig wordt) en een nieuwe aanmaken om deze te vervangen in welke integratie de oude waarde ook gebruikte. Dit is een iets ingrijpender proces dan een "sleutel vergeten"-herstelflow, maar het bestaat precies omdat de sterke versie van dit beveiligingsmodel geen manier heeft om achteraf "wat was mijn sleutel" te beantwoorden — de afweging is bewust.

Wat Het Verwijderen Van Een Sleutel Daadwerkelijk Doet

Het intrekken van een sleutel verwijdert het record volledig in plaats van het ter plekke te deactiveren. Omdat authenticatie werkt door een binnenkomende sleutel te hashen en te zoeken naar een overeenkomende opgeslagen hash, is er zodra het record weg is niets meer waar een verzoek met de oude sleutel tegen kan matchen — het faalt onmiddellijk bij het eerstvolgende verzoek, zonder respijtperiode of vertraging.

Veelgestelde Vragen

Kan ik een gedeeltelijke versie van mijn sleutel zien, zoals de laatste vier tekens, om deze later te helpen identificeren? Momenteel niet — alleen de naam en tijdstempels worden bewaard voor identificatie. Als je meerdere sleutels beheert, is het geven van een duidelijk beschrijvende naam bij het aanmaken de praktische manier om bij te houden welke welke is.

Als ik per ongeluk een sleutel intrek, kan ik hem dan terugkrijgen? Nee — intrekking verwijdert het record, en de oorspronkelijke sleutelwaarde was om te beginnen nooit opgeslagen, dus er is niets te herstellen. Je zou een nieuwe sleutel genereren en bijwerken wat de oude gebruikte.

Heeft elke API-sleutel hetzelfde toegangsniveau, of kunnen ze worden afgebakend? Sleutels zijn gekoppeld aan je werkruimte als geheel in plaats van individueel afgebakend te zijn tot specifieke rechten, dus elke geldige sleutel voor een werkruimte kan de acties uitvoeren waarvoor je account is geautoriseerd. Als je integreert met meerdere externe diensten, maakt het gebruik van een aparte sleutel per integratie — in plaats van één gedeelde sleutel overal — het gemakkelijk om toegang voor één integratie in te trekken zonder de andere te beïnvloeden.