Parhaat käytännöt turvallisten API-avainten rakentamiseen

Me kaikki tiedämme, kuinka arvokkaat sovellusliittymät ovat. Ne ovat portti muiden palveluiden tutkimiseen, integrointiin niiden kanssa ja hyvien ratkaisujen rakentamiseen nopeammin.

Olet saattanut rakentaa tai ajatella rakentaa sovellusliittymiä muiden kehittäjien käyttöön. Sovellusliittymä tarvitsee jonkinlaisen todennuksen, jotta se voi antaa valtuutetun pääsyn palautettaviin tietoihin.

Nykyään on olemassa useita todennusstandardeja, kuten API-avaimet, OAuth, JWT jne.

Tässä artikkelissa tarkastellaan, kuinka API-avaimia voidaan hallita API: n käyttämiseksi.

Joten miksi API-avaimet?

API-avaimet ovat yksinkertaisia ​​käyttää, ne ovat lyhyitä, staattisia ja eivät vanhene, ellei niitä peruta. Ne tarjoavat helpon tavan useille palveluille kommunikoida.

Jos annat asiakkaillesi käyttöliittymän kuluttamiseen, sinun on välttämätöntä rakentaa se oikealla tavalla.

Aloitetaan, ja näytän sinulle, kuinka API-avaimet rakennetaan oikealla tavalla.

API-avaimen luonti

Koska API-avain itsessään on identiteetti, jolla sovellus tai käyttäjä voidaan tunnistaa, sen on oltava ainutlaatuinen, satunnainen ja arvaamaton. Luoduissa API-avaimissa on käytettävä myös aakkosnumeerisia ja erikoismerkkejä. Esimerkki tällaisesta API-avaimesta on zaCELgL.0imfnc8mVLWwsAawjYr4Rx-Af50DDqtlx.

Suojattu API-avaintallennus

Koska API-avain tarjoaa suoran pääsyn tietoihin, se on melkein kuin salasana, jonka verkko- tai mobiilisovelluksen käyttäjä antaa päästä käsiksi samoihin tietoihin.

Ajattele sitä. Syy, miksi meidän on tallennettava API-avaimet, on varmistaa, että pyynnössä oleva API-avain on kelvollinen ja että se on meille annettu (aivan kuten salasana).

Meidän ei tarvitse tietää raakaa API-avainta, mutta meidän on vain vahvistettava, että avain on oikea. Joten sen sijaan, että säilytämme avaimen pelkkänä tekstinä (huono) tai salaamme sen, meidän tulisi tallentaa se hajautettuna arvona tietokantaamme.

Hajautettu arvo tarkoittaa, että vaikka joku saisi luvattoman pääsyn tietokantaamme, API-avaimia ei vuoda ja kaikki on turvallista. Loppukäyttäjä lähettää raakaa API-avainta jokaisessa API-pyynnössä, ja voimme vahvistaa sen hajauttamalla API-avaimen pyyntöön ja vertaamalla tiivistettyä avainta tietokantamme tallennettuun hashiin. Tässä on karkea toteutus Java:

Yllä olevassa koodissa ensisijainen avain on API-avaimen etuliitteen ja tiivisteen yhdistelmä {prefix}.{hash_of_whole_api_key}.

Mutta pidä kiinni, on enemmän. Hajautetun arvon tallentaminen tuo erityisiä käytettävyysongelmia. Tarkastellaan niitä nyt.

API-avaimen esittely käyttäjille

Koska emme tallenna alkuperäistä API-avainta, voimme näyttää sen vain kerran käyttäjälle luontihetkellä. Muista siis ilmoittaa käyttäjille, että sitä ei voi hakea uudelleen, ja heidän on luotava uusi tunnus, jos unohdetaan kopioida API-avain ja tallentaa se turvallisesti. Voit tehdä jotain tällaista:

Kuinka käyttäjät voivat tunnistaa luodun API-avaimen myöhemmin

Toinen ongelma on, kuinka käyttäjät tunnistavat oikean API-avaimen konsolissasi, jos heidän on muokattava tai peruutettava se. Tämä voidaan ratkaista lisäämällä etuliite API-avaimeen. Huomaa kuvassa ensimmäisten 7 merkin (se on etuliitteemme) yläpuolella , erotettuna pisteellä.

Nyt voit tallentaa tämän etuliitteen tietokantaan ja näyttää sen konsolissa, jotta käyttäjät voivat nopeasti tunnistaa oikean API-avaimen merkinnän, kuten tämä:

Älä anna API-avaimelle kaikkea voimaa

Yksi yleinen virhe, jonka API-avaintarjoajat tekevät, on yhden avaimen tarjoaminen kaikkeen pääsyyn , koska sitä on helppo hallita. Älä tee niin. Oletetaan, että käyttäjän tarvitsee vain lukea sähköposti ja luoda API-avain. Mutta tällä avaimella on nyt täysi pääsy muihin palveluihin, mukaan lukien tietueiden poistaminen tietokannasta.

Oikeus lähestymistapa on antaa loppukäyttäjien oikein rajoittaa Sovellusliittymäavain pääsyä ja valitse erityistoimia että API avain voi suorittaa. Tämä voidaan tehdä tarjoamalla laajuuksia , joissa kukin laajuus edustaa erityistä lupaa.

Esimerkiksi,

  • jos tarvitset API-avaimen vain sähköpostien lähettämiseen, voit luoda API-avaimen, jonka laajuus on "email.send"
  • jos loppukäyttäjällä on useita palvelimia ja kukin suorittaa tietyn toiminnon, erillinen API-avain voidaan luoda tietyllä laajuudella.

Joten luotaessasi API-avainta, anna käyttäjien valita, minkä käyttöoikeuden kyseisellä API-avaimella pitäisi olla, kuten alla olevassa kuvassa.

Tällä tavalla käyttäjät voivat luoda useita API-avaimia, joista jokaisella on erityiset pääsysäännöt paremman turvallisuuden takaamiseksi. Ja kun API-pyyntö vastaanotetaan, voit tarkistaa, onko API-avaimella oikea käyttömahdollisuus kyseiseen API: han. Nyt tietokanta näyttää tältä:

Nopeutta rajoittavat API-avaimet

Kyllä, saatat jo tietää sen, mutta on tärkeää arvioida tietyillä API-avaimilla tehtyjä rajoituspyyntöjä, jotta kukaan huono toimija ei voi poistaa API-palvelimiasi tai aiheuttaa suorituskykyongelmia, jotka vaikuttavat muihin asiakkaisiisi. Asianmukainen nopeudenrajoitus- ja seurantaratkaisu pitää API-palvelun terveenä.

Johtopäätös

Kun API-avaimet on rakennettu oikein, ne ovat edelleen hyvä tapa kommunikoida toisen palvelimen kanssa. Kuten olemme tarkastelleet tässä artikkelissa, tiettyjen käytäntöjen noudattaminen tarjoaa etuja sekä API-kuluttajille että API-tarjoajille. Toivottavasti tämä auttaa sinua.

Hyvää sovellusliittymien suojaamista!