API:n valtuutusmenetelmät

Johdanto#

Nykypäivän maailmassa API:t ovat modernien sovellusten selkäranka. Ne ovat ensisijainen tapa saada tietoa ja toimintoja back-end-palveluista. API:t sallivat eri ohjelmistojärjestelmien eri osapuolilta kommunikoida ja jakaa tietoja keskenään, mikä tekee niistä välttämättömiä yrityksille. Kuitenkin API:t ovat myös yleinen kohde hyökkääjille. Tarve API-suojaukselle on vahvempi kuin koskaan.

API-suojaus on prosessi, jolla suojataan API:t luvattomalta käytöltä, väärinkäytöltä ja hyökkäyksiltä. Se on kriittinen osa mitä tahansa API-strategiaa. Tässä artikkelissa tutkimme kolmea yleistä API-suojausmekanismia: API-avaimia, perusautentikointia ja OAuth JWT -tokeneita. Lopuksi näytämme myös, kuinka Logto suojaa API:tasi käyttämällä OAuth JWT -tokeneita.

API-avaimet#

API-avain on yksinkertaisin ja laajimmin käytetty menetelmä API:iden suojaamiseen. API-avain on pitkä merkkijono, jonka API-tarjoaja luo ja jakaa valtuutettujen käyttäjien kanssa. Tämä avain on sisällytettävä pyyntöotsikkoon, kun käytät API:a. API-avaimet ovat yksinkertaisia ja tehokkaita perus-suojaustarpeisiin. Esimerkiksi suositut palvelut, kuten Google Maps API ja AWS, tarjoavat API-avaimia käytön hallintaan ja seurantaan. Kuitenkin ne ovat rajallisia turvallisuuden osalta. Ne käytetään usein koneiden välisessä viestinnässä.

esim.

Plussat:#

• Yksinkertainen toteuttaa: API-avaimet on helppo toteuttaa ja käyttää. Niihin liittyy avaimen lisääminen pyyntöotsikkoon, mikä on suoraviivainen menetelmä kehittäjille ja asiakkaille ymmärtää ja soveltaa.
• Helppo seurata: API-avaimia on helppo seurata. Voit jäljittää jokaisen avaimen käyttö ja peruuttaa ne tarvittaessa.
• Tehokas rajoittaminen: API-avaimet ovat tehokkaita rajoittamiseen. Voit asettaa rajoituksen avainta kohden pyyntöjen määrälle väärinkäytön estämiseksi.
• Sopii ei-herkille tiedoille: API-avaimet soveltuvat ei-herkille tiedoille tai julkisesti saatavilla oleville API:lle, joissa tietoturvavaatimukset ovat alhaisemmat.

Miinukset:#

• Rajoitettu turvallisuus: API-avaimet eivät ole tarpeeksi turvallisia herkille tiedoille, erityisesti asiakaspään sovelluksille. Ne käytetään usein koneiden välisessä viestinnässä.
• Ei sovellu käyttäjäautentikointiin: API-avaimet liittyvät sovelluksiin tai järjestelmiin, ei yksittäisiin käyttäjiin, mikä tekee haastavaksi tunnistaa tiettyjä käyttäjiä tai seurata heidän toimiaan.
• Ei tokenin vanhentumista: API-avaimet ovat yleensä staattisia eivätkä vanhene. Jos avain vaarantuu, sitä voidaan käyttää väärin loputtomasti, ellei sitä uusita manuaalisesti.

Perusautentikointi#

Perusautentikointi on toinen yleinen menetelmä API:iden suojaamiseen. Se on yksinkertainen autentikointijärjestelmä, joka on sisäänrakennettu HTTPs-protokollaan. Se sisältää käyttäjätunnuksen ja salasanan lähettämisen pyyntöotsikossa. Palvelin tarkistaa tunnistetiedot ja palauttaa pyydetyn resurssin, jos ne ovat voimassa. Esimerkiksi monet verkkosovellukset ja RESTful API:t käyttävät perusautentikointia nopeana ja helppona tapana tunnistaa käyttäjät. Perusautentikointi on turvallisempi kuin API-avaimet, koska se käyttää käyttäjätunnusta ja salasanaa staattisen avaimen sijaan. Se ei kuitenkaan ole tarpeeksi turvallinen herkille tiedoille. Koska asiakastiedot lähetetään selväkielisenä, ne ovat alttiita sieppaukselle. Perusautentikointi sopii sisäisiin järjestelmiin, joissa verkkoyhteys on suojattu esim. koneiden välisessä yhteydessä.

esim.

or

Plussat:#

• Vahvempi turvallisuus: Perusautentikointi on turvallisempi kuin API-avaimet, koska se käyttää käyttäjätunnusta ja salasanaa staattisen avaimen sijaan.
• Laajasti tuettu: Perusautentikointia käytetään laajasti ja se on tuettu useimmissa verkkopalvelimissa ja selaimissa.
• Yksinkertaisuus: Kuten API-avaimet, perusautentikointi on suhteellisen yksinkertainen asentaa ja käyttää.

Miinukset:#

• Tunnistetietojen altistuminen: Perusautentikointi lähettää tunnistetiedot selväkielisenä, mikä tekee niistä alttiita sieppaukselle, ellei niitä käytetä suojatun yhteyden (HTTPS) kautta.
• Ei tokenin vanhentumista: Perusautentikointi ei tue tokenin vanhentumista. Jos token vaarantuu, sitä voidaan käyttää väärin loputtomasti, ellei sitä uusita manuaalisesti.

OAuth JWT -tokenit#

JSON Web Token (JWT), määriteltynä RFC 7519, on avoin standardi, joka mahdollistaa tiedon turvallisen välittämisen osapuolten välillä JSON-objektina. Sitä käytetään yleisesti autentikointiin ja valtuutukseen verkkosovelluksissa ja API:issa.

Alle kirjoitetulla JWT:llä on seuraava muoto:

Se koostuu kolmesta osasta, jotka on erotettu .: otsikko, hyötykuorma ja allekirjoitus.

Tässä on esimerkki JWT:stä:

• otsikko: sisältää tietoa tokenin tyypistä ja hashauksen algoritmista, jota käytettiin sen allekirjoittamiseen.
• hyötykuorma: sisältää vaatimukset (lausunnot) käyttäjästä ja muista tiedoista.
• allekirjoitus: on otsikon ja hyötykuorman allekirjoitettu hash, salaisella avaimella.

OAuth on kattava avoin standardi API:iden suojaamiseksi. ja pääsyn delegoimiseksi, jota käytetään yleisesti tapana, jossa asiakaskäyttäjät myöntävät verkkosivustoille tai sovelluksille pääsyn tietoihinsa muilla verkkosivustoilla ilman, että antavat heille salasanansa.

Kun OAuth ja JWT yhdistetään, OAuth JWT -tokeneissa saavutetaan vahva turvallisuusratkaisu. Sen sijaan, että lähettäisit herkkää tietoa, kuten käyttäjätunnuksia ja salasanoja jokaisessa pyynnössä, OAuth JWT -welkaarten myönnetään valtuutetuille asiakkaille onnistuneen autentikoinnin jälkeen. Näissä tokeneissa on tietoa käyttäjästä ja hänen oikeuksistaan. Lisäksi JWT-tokenit on digitaalisesti allekirjoitettuja väärentämisen estämiseksi, ja ne voidaan asettaa vanhentumaan. Tämä tuo lisäturvakerroksen.

Yksi keskeinen etu OAuth JWT -tokeneissa on niiden joustavuus. Niitä voidaan käyttää monenlaisissa sovelluksissa, kuten verkkosovelluksissa ja mobiilisovelluksissa, kertakirjautumisratkaisuina ja muissa. Esimerkiksi suuret sosiaalisen median alustat, kuten Facebook, Twitter ja LinkedIn, käyttävät OAuth JWT -tokeneita autentikoidakseen käyttäjiä ja mahdollistaakseen kolmannen osapuolen sovellusten turvallisen pääsyn käyttäjätietoihin.

Plussat:#

• Parempi turvallisuus: OAuth JWT -tokenit tarjoavat korkeamman tason turvallisuuden. Ne ovat digitaalisesti allekirjoitettuja ja niitä voidaan salata, mikä vähentää luvattoman käytön ja datan peukaloinnin riskiä.
• Käyttäjäidentiteetti ja pääsynhallinta: JWT-tokenit voivat sisältää käyttäjäidentiteettitietoa ja vaatimuksia, jotka määrittävät, mitkä toiminnot tai resurssit käyttäjä on valtuutettu käyttämään.
• Hienojakoinen pääsynhallinta: JWT-tokenit voivat toteuttaa hienojakoista pääsynhallintaa. Esimerkiksi voit määrittää, mihin resursseihin käyttäjä voi päästä ja mitä toimintoja hän voi suorittaa näille resursseille.
• Tokenin vanhentuminen: OAuth JWT -tokenit voidaan asettaa vanhentumaan tietyn ajanjakson jälkeen, mikä vähentää väärinkäytön riskiä.

Miinukset:#

• Monimutkaisuus: OAuth JWT -tokenit ovat monimutkaisempia kuin API-avaimet ja perusautentikointi. Ne vaativat lisäaskeleita asennuksessa ja käytössä.
• Tokenin hallinta: OAuth JWT -tokeneita on hallittava ja peruutettava tarvittaessa. Tämä voi olla haastavaa laajamittaisissa sovelluksissa, joissa on paljon käyttäjiä ja asiakkaita.
• Resurssien kulutus: Tokenien luominen ja validointi voi aiheuttaa jonkin verran suorituskykyhaittaa, mikä voi olla huolenaihe korkean liikenteen tilanteissa.

Logto API -suojaus#

Autentikointimenetelmän valinta riippuu sovelluksesi erityisvaatimuksista ja tietoturvanäkökohdista. API-avaimet ovat yksinkertaisia, mutta vähemmän turvallisia, perusautentikointi tarjoaa enemmän turvallisuutta, mutta puuttuu käyttäjäidentiteettiominaisuuksia, kun taas OAuth JWT -tokenit antavat vahva turvallisuus- ja käyttäjäidentiteettikapasiteetin, mutta lisäävät monimutkaisuutta toteutuksessa ja hallinnassa.

Logto tarjoaa yksinkertaisen ja turvallisen tavan suojata API:asi käyttämällä OAuth JWT -tokeneita. Se tukee sekä OAuth 2.0 että OpenID Connect (OIDC) standardeja, jolloin voit valita autentikointimenetelmän, joka parhaiten sopii tarpeisiisi. Voit käyttää client_credentials -prosessia koneiden väliseen viestintään ja authorization_code -prosessia verkkosovelluksille.

Koneiden välinen viestintä#

Logto käyttää client_credentials -prosessia koneiden välisiin sovellustyyppeihin. Tämä prosessi sopii taustapalvelimien viestintään, jossa asiakas on luotettava asiakas, joka voi turvallisesti tallentaa asiakastunnukset. Se tunnetaan myös nimellä "kaksijalkainen OAuth", koska se ei sisällä käyttäjää. Asiakastunnuksia käytetään suoraan valtuutuksena myöntämään käyttöoikeustoken.

Integraatioprosessi on yksinkertainen ja suoraviivainen:

1. Luo API-resurssi Logto Consoleen.
2. Luo koneiden välinen asiakas Logto Consoleen.
3. Lähetä pyyntö Logto tokenin päätepisteeseen saadaksesi käyttöoikeustoken.

4. Pääse suojattuun resurssiin käyttöoikeustokenilla.

Katso lisätietoja koneiden välisestä integrointiasiakirmasta täältä.

Verkkosovellukset#

Julkisille asiakkaille, kuten verkkosovelluksille, Logto käyttää authorization_code -prosessia käyttäjien autentikointiin. Tämä prosessi sopii verkkosovelluksille, joissa asiakas on julkinen asiakas, joka ei voi turvallisesti tallentaa asiakastunnuksia. Se tunnetaan myös nimellä "kolmejalkainen OAuth", koska siihen sisältyy käyttäjä. Käyttäjä ohjataan valtuutettuun palvelimeen autentikoitumaan ja valtuuttamaan asiakas. Asiakas käyttää sitten valtuutuskoodia saadakseen käyttöoikeustokenin.

Integraatioprosessi on hieman monimutkaisempi kuin koneiden välinen prosessi:

Katso lisätietoja, tutustu artikkeliimme Suojaa Express.js API:si JWT:llä ja Logtolla, joka on kattava esimerkki siitä, kuinka integroidaan Logto Reactin kanssa ja pääset Express-palvelimen API:hin JWT: tokenien avulla.