Henkilökohtaiset käyttöoikeustunnukset, koneiden välinen autentikointi ja API-avainten määritelmät

Jos rakennat ohjelmistoa tai SaaS-tuotetta, kohtaat usein laajan käyttötapauksen tai ominaisuuspyynnön: API-pyynnöt. Erityisesti suuret yritysasiakkaat voivat haluta ohjelmallista pääsyä resursseihin joko henkilökohtaisella tai organisatorisella tasolla.

Näissä tapauksissa tarvitaan usein API-avaimia, henkilökohtaisia käyttöoikeustunnuksia (PAT) ja koneiden välistä (M2M) autentikointia. Tässä artikkelissa tutkimme näiden menetelmien eroja ja niiden käyttöä B2B-tuotekehityksessä kehittäjille.

Yhtäläisyydet#

Katsotaanpa ensin näiden kolmen yhteisiä piirteitä.

1. Turvallisuustarkoitus: Kaikkia kolmea menetelmää käytetään API:en, palveluiden tai resurssien suojaamiseen ja pääsyn hallintaan. Ne kaikki toimivat autentikoinnin ja/tai valtuutuksen keinona.
2. Tunnuspohjainen lähestymistapa: Jokainen menetelmä sisältää tyypillisesti ainutlaatuisen merkkijonon tai tunnuksen käytön tunnistamiseen. Nämä tunnukset lähetetään yleensä API-pyyntöjen mukana, usein otsikoissa tai kyselyparametreina.
3. Peruutettavissa: Kaikkien kolmen menetelmän tunnukset tai avaimet voidaan peruuttaa tai mitätöidä, jos ne vaarantuvat tai niitä ei enää tarvita. Tämä mahdollistaa nopean turvallisuusvasteen ilman, että tarvitsee muuttaa taustajärjestelmää.
4. Ohjelmallinen pääsy: Kaikki kolme menetelmää mahdollistavat ohjelmallisen pääsyn API:en tai palveluihin. Ne mahdollistavat automaation ja integraation eri järjestelmien tai sovellusten välillä.
5. Auditointi: Näiden autentikointimenetelmien käyttö voidaan kirjata ja auditoida. Tämä mahdollistaa API-pääsyn seurannan, epäilyttävien toimintojen valvonnan ja vaatimustenmukaisuusraportoinnin.
6. Sovellettavissa pääsynhallintaan: Kaikki kolme menetelmää voidaan toteuttaa eri tasoisella pääsynhallinnalla ja oikeuksilla. Ne voidaan sovittaa eri turvallisuusmalleihin ja arkkitehtonisiin vaatimuksiin.
7. Protokollariippumattomuus: Vaikka niitä usein käytetään REST API:en kanssa, näitä menetelmiä voidaan soveltaa eri tyyppisiin API:iihin ja protokolliin.

Ymmärtämällä nämä yhtäläisyydet autetaan tunnistamaan näiden autentikointimenetelmien yhteiset perustat. Niiden erot mahdollistavat sopivimman ratkaisun valinnan erityisiin käyttötapauksiin ja turvallisuusvaatimuksiin.

Keskustellaan nyt niiden eroista, keskittyen niiden käyttötapauksiin ja milloin kutakin menetelmää tulisi käyttää.

Erot#

API-avaimet#

API-avaimia käytetään tunnistamaan ja valtuuttamaan kutsuva sovellus tai palvelu. Ne ovat yleensä pitkäikäisiä ja staattisia, kunnes ne kierrätetään, ja niillä on yleensä kiinteä joukko oikeuksia. Niitä käytetään pääasiassa palvelimelta palvelimelle -viestintään tai julkisen datan käyttöön, eikä nämä tunnukset yleensä edusta tiettyä käyttäjää.

Kuinka API-avaimet toimivat?#

API-avain myönnetään API-tarjoajan toimesta ja annetaan rekisteröityneelle API-kuluttajalle [1], joka sisällyttää sen jokaisen pyynnön mukana. API-palvelin tarkistaa sitten API-avaimen vahvistaakseen kuluttajan identiteetin ennen pyydettyjen tietojen palauttamista.

API-avaimet eivät ole yhtä tehokkaita kuin muut API-autentikointi muodot, kuten OAuth ja JWT, mutta ne ovat silti tärkeässä roolissa auttaen API-tuottajia seuraamaan käyttöä pitäen samalla arkaluonteiset tiedot turvassa.

[1]: API-kuluttaja on mikä tahansa sovellus, palvelu tai käyttäjä, joka on vuorovaikutuksessa API:n kanssa saadakseen käyttöönsä sen toiminnallisuuksia tai tietoja. He lähettävät pyyntöjä API:lle suorittaakseen operaatioita, kuten resurssien noutaminen, luominen, päivittäminen tai poistaminen. API-kuluttajat voivat olla verkkosovelluksia, mobiilisovelluksia, muita palvelimia tai jopa yksittäisiä kehittäjiä, jotka käyttävät API:a integroidakseen muihin palveluihin tai rakentaakseen uusia toiminnallisuuksia olemassa olevien alustojen päälle.

Postman: Mikä on API-avain?

Käyttötapaukset#

Kun ihmiset keskustelevat API-avainten käyttötapauksista, he usein mainitsevat automaation, tietojen jaon, testauksen, kehityksen ja turvallisuuden hallinnan. Nämä ovat kuitenkin melko teknisiä. Todellisessa maailmassa yleisin tarkoitus tuotteita rakennettaessa on integraatio.

Esimerkki 1: Integraatio Zapierin kanssa#

Zapier: Lisää autentikointi API-avaimella

Zapier on suosittu automaatiotyökalu, joka yhdistää eri verkkosovelluksia. Kun sovellusta integroidaan Zapierin kanssa, API-avaimia käytetään autentikoimaan ja valtuuttamaan pääsy sovelluksen API:iin. Esimerkiksi, jos haluat automatisoida tehtäviä CRM-järjestelmän ja sähköpostimarkkinointityökalun välillä, luot API-avaimen CRM-järjestelmästä ja annat sen Zapierille. Tätä avainta käytetään sitten autentikoimaan Zapierin pyynnöt CRM:n API:hen, mikä mahdollistaa tietojen suojatun virran näiden kahden järjestelmän välillä.

Esimerkki 2: Integraatio Stripen kanssa#

Stripe hyödyntää API-avaimia turvalliseen integraatioon eri alustojen ja sovellusten kanssa. Käytä Kehittäjien hallintapaneelia luodaksesi, paljastaaksesi, poistaaksesi ja kierrättääksesi API-avaimia.

Henkilökohtaiset käyttöoikeustunnukset (PATs)#

Henkilökohtainen käyttöoikeustunnus on toinen vastaava käsite, mutta se edustaa tietyn käyttäjän identiteettiä ja oikeuksia, se luodaan dynaamisesti onnistuneen autentikoinnin tai kirjautumisen jälkeen ja sillä on yleensä rajoitettu elinikä, mutta se voidaan päivittää. Ne tarjoavat hienojakoista pääsynhallintaa käyttäjäkohtaisiin tietoihin ja ominaisuuksiin ja niitä käytetään yleisesti CLI-työkaluissa, skripteissä tai henkilökohtaisessa API-pääsyssä.

Kuinka PAT:t toimivat#

1. Luominen ja hallinta: Käyttäjät luovat PAT:t tiliasetustensa kautta kyseessä olevassa alustalla.
   • Esimerkiksi GitHubissa käyttäjät voivat luoda hienojakoisia tai klassisia PAT-tunnuksia tietyillä oikeuksilla ja vanhentumispäivillä.
   • Atlassianin tuotteissa, kuten Jira ja Confluence, käyttäjät voivat luoda PAT-tunnuksia profiiliasetuksissaan määrittäen tunnuksen nimen ja valinnaisen vanhentumisajan.
2. Käyttö: PAT:iä käytetään kantajatunnuksina API-pyyntöjen Authorization-otsikossa. Tämä tarkoittaa, että ne sisällytetään HTTP-otsikoihin pyynnön autentikoimiseksi.
   • Ne mahdollistavat turvallisen pääsyn API-resursseihin, antaen käyttäjien suorittaa toimia, kuten resurssien luominen, lukeminen, päivittäminen ja poistaminen myönnettyjen oikeuksien perusteella.
   • PAT:t voivat olla käytössä useissa sovelluksissa yhden alustan sisällä, tarjoten yhtenäisen tavan hallita pääsyä ja oikeuksia.
3. Peruutus ja vanhenemisen asettaminen:
   • PAT:t tarjoavat parannetun turvallisuuden, jolloin käyttäjä voi peruuttaa tunnuksen, jos se vaarantuu, ilman että tarvitsee muuttaa tilin salasanaa.
   • Alustat suosittelevat usein asettamaan PAT-tunnuksille vanhentumispäiviä vähentääkseen pitkäikäisten tunnusten käyttöä.

Käyttötapaukset#

On kaksi tyypillistä skenaariota,

Automaatio ja skriptaus

Tämä tarkoittaa sitä, kun kehittäjä käyttää PAT:iä koodin automaattiseen käyttöönottamiseen varastosta tuotantoympäristöön, vähentäen manuaalista väliintuloa ja varmistaen johdonmukaisuuden.

Esimerkiksi GitHub-käyttäjät voivat luoda PAT-tunnuksia autentikoimaan Git-toiminnot HTTPS-yhteyden kautta ja olla vuorovaikutuksessa GitHubin REST API:n kanssa. Tämä on hyödyllistä kehittäjille, jotka tarvitsevat automatisoida tehtäviä, kuten varastojen kloonaamisen, sitoumusten työntämisen tai ongelmien ja vetopyyntöjen hallinnan.

Integraatio ulkopuolisten sovellusten kanssa

Tämä tarkoittaa, että mahdollistetaan turvallinen viestintä eri järjestelmien ja sovellusten välillä. Tämä näyttää samanlaiselta kuin skenaario, jossa API-avaimen integraatio, mutta PAT edustaa käyttäjää, ei asiakasta tai sovellusta.

Esimerkiksi projektipäällikkö käyttää PAT:iä integroidakseen projektinhallintatyökalun ulkoiseen ongelmanseurantajärjestelmään, mahdollistaa saumattoman tiedonvaihdon ja synkronoinnin, kuten Atlassian (Jira ja Confluence).

Yllä olevat skenaariot ovat enemmän kehittäjätyökaluja. Ovatko PAT:it vain hyödyllisiä tällaisille tuotteille? Ei. Tässä on kaksi lisäesimerkkiä: yksi on CMS-järjestelmä ja yksi on tuottavuustyökalu.

Esimerkki 1: Contentful#

Contentful: Henkilökohtaiset käyttöoikeustunnukset

Contentful on headless CMS-alusta, joka tarjoaa PAT-tunnuksia vaihtoehtona OAuth-tunnuksille Content Management API:n (CMA) käytölle.

Avainominaisuuksia ovat:

• Käyttäjät voivat luoda useita tunnuksia eri laajuuksilla ja oikeuksilla.
• Tunnukset liittyvät käyttäjän tiliin ja perivät heidän oikeutensa.
• PAT:t ovat erityisen hyödyllisiä kehitys- ja automaatiotarkoituksissa.

Esimerkki 2: Airtable#

Henkilökohtaisten käyttöoikeustunnusten luominen | Airtable-tuki

Airtable - pilvikollaboraatioalusta, käyttää PAT-tunnuksia API-pääsyyn.

Heidän järjestelmänsä sallii:

• Useiden tunnusten luomisen eri laajuuksilla ja pääsytasoilla.
• Tunnukset voidaan rajata tiettyihin perustuksiin tai työtiloihin.
• Yrityksen ylläpitäjät voivat luoda tunnuksia, joilla on laajempi pääsy koko organisaation alueella.

Koneiden välinen (M2M) autentikointi#

M2M on suunniteltu palvelusta palveluun -kommunikaatiota ilman ihmisen väliintuloa. Se perustuu ajatukseen, että käyttäjätunnukset ja salasanat eivät riitä palveluiden suojaamiseen ja eivät ole tehokkaita automaation kannalta.

Koneiden väliset (M2M) sovellukset ottavat nyt käyttöön Client Credentials Flow -virtaustyypin, joka on määritelty OAuth 2.0 RFC 6749 -autentikointiprotokollassa. Se voi myös tukea samankaltaisia standardiprotokollia. Kyllä, M2M-autentikointi on avoimen standardin suhteen tiukempaa verrattuna PAT:eihin ja API-avaimiin.

Se autentikoi sovelluksen tai palvelun itsensä, ei käyttäjää, ja toteuttaa usein JWT:tä (JSON Web Tokens) tilattomaan autentikointiin. Tämä tarjoaa turvallisen tavan palveluiden väettämättömään viestintään hajautetuissa järjestelmissä.

Kuinka koneiden välinen autentikointi toimii#

Se noudattaa samanlaista prosessia:

1. Asiakastunnukset: Jokaisella koneella (tai palvelulla) on ainutlaatuinen asiakastunnus ja salaisuus.
2. Tunnuspyyntö: Palvelu lähettää nämä tunnukset valtuutuspalvelimelle.
3. Pääsytunnus: Validaation jälkeen valtuutuspalvelin myöntää pääsytunnuksen, usein JWT (JSON Web Token) muodossa.
4. API-pyynnöt: Palvelu käyttää tätä tunnusta autentikoimaan ja valtuuttamaan API-pyynnöt toiseen palveluun.
5. Validaatio: Vastaanottava palvelu validoi tunnuksen ennen käyttöoikeuden myöntämistä sen resursseihin.

Käyttötapaukset#

Tässä on tiivis esimerkki koneiden välisen (M2M) autentikoinnin käytöstä taustapalvelujen välisessä viestinnässä:

Skenaario: Palvelu A tarvitsee pääsyn palvelun B API:in tietoihin.

1. Asennus:

   • Palvelu A rekisteröidään asiakkaaksi valtuutuspalvelimella.
   • Palvelulle A annetaan asiakastunnus ja asiakassalaisuus.

2. Autentikointi:

   • Palvelu A pyytää pääsytunnusta valtuutuspalvelimelta:

3. Tunnuksen myöntäminen:

   • Valtuutuspalvelin varmistaa tunnukset ja myöntää JWT-pääsytunnuksen.

4. API-pyyntö:

   • Palvelu A käyttää tunnusta pyytääkseen tietoja palvelulta B:

5. Validaatio:

   • Palvelu B validoi tunnuksen valtuutuspalvelimen kanssa.

6. Vastaus:

   • Jos se on validi, palvelu B palauttaa pyydetyt tiedot palvelulle A.

Tämä prosessi mahdollistaa turvallisen, automatisoidun viestinnän palvelujen A ja B välillä ilman käyttäjän väliintuloa, käyttäen OAuth 2.0 -asiakastunnusvirtausta.

Laitteiden välinen viestintä

Laitteiden välinen viestintä, erityisesti IoT (Internet of Things) yhteydessä, nojaa voimakkaasti koneiden välistä (M2M) autentikointia turvallisen ja tehokkaan tiedonvaihdon varmistamiseksi.

Esimerkiksi, kuten älykodin laitteet, älykäs termostaatti kommunikoi keskeisen kotiautomaatiohubin kanssa mukauttaakseen lämpötila-asetuksia käyttäjän mieltymysten perusteella. Termostaatti käyttää M2M-autentikointia turvallisesti lähettääkseen tietoja hubiin ja vastaanottaakseen komentoja, varmistaen, että vain valtuutetut laitteet voivat olla vuorovaikutuksessa kodin lämmitysjärjestelmän kanssa.

Keskeinen yhteenveto#

Ok, olet saavuttanut tämän artikkelin lopun. Voinko saada nopean yhteenvedon? Tietysti! Tässä on keskeiset kohdat:

1. Soveltamisala: API-avaimet ovat laajoja, PAT:t (henkilökohtaiset käyttöoikeustunnukset) ovat käyttäjäkohtaisia, ja M2M (koneiden välinen) tunnukset ovat palvelukohtaisia.
2. Elinikä: API-avaimet ovat pitkäikäisiä, PAT:eillä on lyhyempi elinikä, ja M2M-tunnukset voivat vaihdella.
3. Edustus: API-avaimet ovat läpinäkymättömiä merkkijonoja, PAT:t voivat olla läpinäkymättömiä tai rakenteellisia, ja M2M-tunnukset käyttävät usein JWT:tä.
4. Käyttötapaus: API-avaimet ovat yksinkertaiseen API-pääsyyn, PAT:t ovat käyttäjälähtöisiin operaatioihin, ja M2M-tunnukset ovat palvelusta palveluun -kommunikointiin.