Beste praksis for å bygge sikre API-nøkler

Vi vet alle hvor verdifulle API-er. De er inngangsporten til å utforske andre tjenester, integrere seg med dem og bygge gode løsninger raskere.

Du har kanskje bygget eller tenker på å bygge API-er for andre utviklere å bruke. Et API trenger en form for autentisering for å gi autorisert tilgang til dataene den returnerer.

Det er flere autentiseringsstandarder tilgjengelig i dag, for eksempel API-nøkler, OAuth, JWT, etc.

I denne artikkelen skal vi se på hvordan vi administrerer API-nøkler riktig for å få tilgang til API-er.

Så hvorfor API-nøkler?

API-nøkler er enkle å bruke, de er korte, statiske og utløper ikke med mindre tilbakekalles. De gir en enkel måte for flere tjenester å kommunisere.

Hvis du gir et API for kundene dine å konsumere, er det viktig at du bygger det på riktig måte.

La oss komme i gang, så viser jeg deg hvordan du bygger API-nøkler på riktig måte.

API-nøkkelgenerering

Siden API-nøkkelen i seg selv er en identitet for å identifisere applikasjonen eller brukeren, må den være unik, tilfeldig og ikke antagelig. API-nøkler som genereres, må også bruke alfanumeriske og spesialtegn. Et eksempel på en slik API-nøkkel er zaCELgL.0imfnc8mVLWwsAawjYr4Rx-Af50DDqtlx.

Sikker API-nøkkelberging

Siden API-nøkkelen gir direkte tilgang til data, er det omtrent som et passord som en bruker av en nett- eller mobilapp gir for å få tilgang til de samme dataene.

Tenk på det. Årsaken til at vi trenger å lagre API-nøkler er å sørge for at API-nøkkelen i forespørselen er gyldig og utstedt av oss (akkurat som et passord).

Vi trenger ikke å kjenne den rå API-nøkkelen, men trenger bare å bekrefte at nøkkelen er riktig. Så i stedet for å lagre nøkkelen i ren tekst (dårlig) eller kryptere den, bør vi lagre den som en hashverdi i databasen vår.

En hashverdi betyr at selv om noen får uautorisert tilgang til databasen vår, er ingen API-nøkler lekket og det hele er trygt. Sluttbrukeren vil sende den rå API-nøkkelen i hver API-forespørsel, og vi kan validere den ved å haske API-nøkkelen i forespørselen og sammenligne hash-nøkkelen med hasjen som er lagret i vår database. Her er en grov implementering av den i Java:

I koden over vil den primære nøkkelen være en kombinasjon av prefikset og hasjen til API-nøkkelen {prefiks}. {Hash_of_whole_api_key}.

Men hold på, det er mer. Lagring av en hashverdi gir spesifikke brukervennlighetsproblemer. La oss ta tak i de nå.

Presentere API-nøkkel for brukere

Siden vi ikke lagrer den opprinnelige API-nøkkelen, kan vi vise den bare en gang til brukeren, på tidspunktet for opprettelsen. Så husk å varsle brukere om at den ikke kan hentes igjen, og at de må generere et nytt token hvis de glemmer å kopiere API-nøkkelen og lagre den trygt. Du kan gjøre noe som dette:

Viser generert API-nøkkel med en varselmelding

Hvordan brukere kan identifisere en generert API-nøkkel senere

Et annet problem er hvordan brukere identifiserer riktig API-nøkkel i konsollen din hvis de trenger å redigere eller oppheve den. Dette kan løses ved å legge til et prefiks til API-nøkkelen. Legg merke til på bildet over de første syv tegnene (det er vårt prefiks), atskilt med prikken.

Nå kan du lagre dette prefikset i databasen og vise det i konsollen slik at brukerne raskt kan identifisere riktig API-nøkkeloppføring, slik:

API nøkkeladministrasjonskonsoll

Ikke gi API-nøkkelen all kraft

En vanlig feil som API-nøkkelleverandører gjør er å tilby en nøkkel for å få tilgang til alt, siden det er enkelt å administrere. Ikke gjør det. Anta at en bruker bare trenger å lese en e-post, og genererer en API-nøkkel. Men den nøkkelen har nå full tilgang til andre tjenester, inkludert sletting av poster i databasen.

Den rette tilnærmingen er å la sluttbrukere begrense tilgangen til API-nøkkel på riktig måte og velge spesifikke handlinger som en API-nøkkel kan utføre. Dette kan gjøres ved å tilby omfang, der hvert omfang representerer en spesifikk tillatelse.

For eksempel,

  • Hvis du trenger en API-nøkkel for bare å sende e-post, kan du generere en API-nøkkel med omfanget som "email.send"
  • Hvis sluttbrukeren har flere servere og hver utfører en spesifikk handling, kan en egen API-nøkkel genereres med et bestemt omfang.

Så mens du oppretter API-nøkkelen, lar brukerne velge hvilken tilgang den API-nøkkelen skal ha, som på bildet nedenfor.

På denne måten kan brukere generere flere API-nøkler, hver med spesifikke regler for tilgang for bedre sikkerhet. Og når en API-forespørsel mottas, kan du sjekke om API-nøkkelen har riktig omfang til å få tilgang til det API. Nå ser databasen noe slik ut:

API-nøkkeldatabaseenhet

Rangeringsbegrensende API-nøkler

Ja, du vet kanskje allerede det, men det er viktig å rangere grenseforespørsler fremsatt med spesifikke API-nøkler for å sikre at ingen dårlig aktør kan ta ned API-serverne dine eller forårsake ytelsesproblemer som påvirker dine andre kunder. Å ha en riktig takstbegrensende og overvåkingsløsning holder API-tjenesten sunn.

Konklusjon

API-nøkler, når de er bygget riktig, er fremdeles en flott måte å kommunisere med en annen server. Som vi gjennomgått i denne artikkelen, er det å følge visse fremgangsmåter fordeler for både API-forbrukere og API-leverandører. Håper dette hjelper deg.

Gledelig å sikre APIene dine!