Best practices voor het bouwen van veilige API-sleutels

We weten allemaal hoe waardevol API's zijn. Ze zijn de toegangspoort tot het verkennen van andere services, het integreren ervan en sneller geweldige oplossingen bouwen.

Mogelijk hebt u API's gebouwd of overweegt u deze voor andere ontwikkelaars te gebruiken. Een API heeft een vorm van authenticatie nodig om geautoriseerde toegang te bieden tot de gegevens die het retourneert.

Er zijn tegenwoordig verschillende authenticatiestandaarden beschikbaar zoals API Keys, OAuth, JWT, etc.

In dit artikel bekijken we hoe API-sleutels correct kunnen worden beheerd om toegang te krijgen tot API's.

Dus waarom API-sleutels?

API-sleutels zijn eenvoudig te gebruiken, ze zijn kort, statisch en verlopen niet tenzij ze worden ingetrokken. Ze bieden een gemakkelijke manier voor meerdere services om te communiceren.

Als u een API verstrekt die uw klanten kunnen gebruiken, is het essentieel dat u deze op de juiste manier bouwt.

Laten we beginnen, en ik zal je laten zien hoe je API-sleutels op de juiste manier kunt bouwen.

API Key Generation

Aangezien de API-sleutel zelf een identiteit is waarmee de toepassing of de gebruiker kan worden geïdentificeerd, moet deze uniek, willekeurig en niet te raden zijn. API-sleutels die worden gegenereerd, moeten ook alfanumerieke en speciale tekens gebruiken. Een voorbeeld van een dergelijke API-sleutel is zaCELgL.0imfnc8mVLWwsAawjYr4Rx-Af50DDqtlx.

Veilige API Key Storage

Aangezien de API-sleutel directe toegang tot gegevens biedt, is het vrijwel een wachtwoord dat een gebruiker van een web- of mobiele app biedt om toegang te krijgen tot dezelfde gegevens.

Denk er over na. De reden dat we API-sleutels moeten opslaan, is om ervoor te zorgen dat de API-sleutel in de aanvraag geldig is en door ons wordt uitgegeven (net als een wachtwoord).

We hoeven de onbewerkte API-sleutel niet te kennen, maar moeten alleen valideren dat de sleutel correct is. Dus in plaats van de sleutel in platte tekst (slecht) op te slaan of te versleutelen, moeten we deze als een hashwaarde in onze database opslaan.

Een hash-waarde betekent dat zelfs als iemand ongeautoriseerde toegang tot onze database krijgt, er geen API-sleutels zijn uitgelekt en alles veilig is. De eindgebruiker stuurt de onbewerkte API-sleutel in elk API-verzoek en we kunnen deze valideren door de API-sleutel in het verzoek te hashen en de gehashte sleutel te vergelijken met de hash die in onze database is opgeslagen. Hier is een ruwe implementatie ervan in Java:

In de bovenstaande code is de primaire sleutel een combinatie van het voorvoegsel en de hash van de API-sleutel {prefix}. {Hash_of_whole_api_key}.

Maar wacht even, er is meer. Het opslaan van een hash-waarde levert specifieke bruikbaarheidsproblemen op. Laten we die nu behandelen.

De API Key presenteren aan gebruikers

Omdat we de originele API-sleutel niet opslaan, kunnen we deze slechts één keer aan de gebruiker laten zien, op het moment van aanmaken. Zorg er dus voor dat gebruikers worden gewaarschuwd dat het niet meer kan worden opgehaald en dat ze een nieuw token moeten genereren als ze vergeten de API-sleutel te kopiëren en veilig op te slaan. Je kunt zoiets doen:

Gegenereerde API-sleutel weergeven met een waarschuwingsbericht

Hoe gebruikers later een gegenereerde API-sleutel kunnen identificeren

Een ander probleem is hoe gebruikers de juiste API-sleutel in uw console identificeren als ze deze moeten bewerken of intrekken. Dit kan worden opgelost door een prefix aan de API-sleutel toe te voegen. Let op de afbeelding boven de eerste 7 tekens (dat is ons voorvoegsel), gescheiden door de stip.

Nu kunt u dit voorvoegsel in de database opslaan en in de console weergeven, zodat gebruikers snel de juiste API-sleutelinvoer kunnen identificeren, zoals hier:

API Key-beheerconsole

Geef de API Key niet alle kracht

Een veel voorkomende fout die providers van API-sleutels maken, is het bieden van één sleutel voor toegang tot alles, omdat deze eenvoudig te beheren is. Doe dat niet. Stel dat een gebruiker alleen een e-mail moet lezen en een API-sleutel genereert. Maar die sleutel heeft nu volledige toegang tot andere services, inclusief het verwijderen van records in de database.

De juiste aanpak is om de eindgebruikers de toegang tot de API-sleutel naar behoren te laten beperken en specifieke acties te kiezen die een API-sleutel kan uitvoeren. Dit kan worden gedaan door scopes aan te bieden, waarbij elke scope een specifieke toestemming vertegenwoordigt.

Bijvoorbeeld,

  • als u een API-sleutel nodig hebt om alleen e-mails te verzenden, kunt u een API-sleutel genereren met de scope als "email.send"
  • Als de eindgebruiker meerdere servers heeft en elk een specifieke actie uitvoert, kan een afzonderlijke API-sleutel worden gegenereerd met een specifiek bereik.

Laat gebruikers bij het maken van de API-sleutel dus kiezen welke toegang die API-sleutel moet hebben, zoals in de onderstaande afbeelding.

Op deze manier kunnen gebruikers meerdere API-sleutels genereren, elk met specifieke toegangsregels voor betere beveiliging. En wanneer een API-verzoek wordt ontvangen, kunt u controleren of de API-sleutel de juiste reikwijdte heeft om toegang te krijgen tot die API. Nu ziet de database er ongeveer zo uit:

API Key-database-entiteit

Snelheidsbeperkende API-sleutels

Ja, je weet het misschien al, maar het is belangrijk om limietaanvragen te beoordelen die zijn gedaan met specifieke API-sleutels om ervoor te zorgen dat geen slechte actor je API-servers kan uitschakelen of prestatieproblemen kan veroorzaken die je andere klanten beïnvloeden. Het hebben van een juiste snelheidsbeperkende en bewakingsoplossing houdt de API-service gezond.

Gevolgtrekking

API-sleutels zijn, wanneer ze goed zijn gebouwd, nog steeds een geweldige manier om met een andere server te communiceren. Zoals we in dit artikel hebben beoordeeld, biedt het volgen van bepaalde werkwijzen voordelen voor zowel API-consumenten als API-providers. Ik hoop dat dit je helpt.

Veel plezier met het beveiligen van uw API's!