Ohjelmallinen todennus: API-avain, henkilökohtainen käyttötunnus ja OAuth-asiakastunnistetietojen virtaus

Tausta#

Ohjelmistokehityksessä, kun meidän täytyy ohjelmallisesti käyttää API-resursseja CLI-komentojen kautta tai luoda yhteyksiä backend-palveluiden välille, on yleensä kolme todennusmekanismia, jotka ovat laajalti käytössä kehittäjien toimesta: API-avain, henkilökohtainen käyttötunnus (PAT) ja OAuth-asiakastunnistetietojen virtaus (brändättynä kone-keinokoneeksi Logto:ssa). Mutta mitkä ovat niiden väliset erot? Mikä on paras käyttötapaus kullekin näistä menetelmistä? Tässä blogikirjoituksessa käsittelemme niiden samankaltaisuuksia, eroja, ja tarjoamme oivalluksia siitä, milloin niitä kannattaa käyttää eri tilanteissa.

Määritelmät#

• API-avain: Yksinkertainen merkkijono, joka voi todentaa pyyntösi API-resursseihin.
• Henkilökohtainen käyttötunnus (PAT): Myös yksinkertainen merkkijono, mutta edustaa käyttäjää, kun sitä käytetään tunnistautumaan API-resursseihin. Se on käyttäjän delegointi.
• Logto kone-keinokone (Logto M2M): Vakio OAuth-asiakastunnistetietojen virtaus, joka vaatii asiakkaan rekisteröimistä etukäteen, ja vaatii asiakastunnuksen ja salaisuuden käyttämistä käyttöoikeustunnuksen vaihtamiseksi. Näin ollen Logto M2M -tunnistetiedot edustavat luotettua asiakasta ja OAuth-asiakastunnistetietojen virtauksen luonne tekee siitä suhteellisen monimutkaisen käyttää.

Samankaltaisuudet#

1. Todennustarkoitus#

• Kaikki kolme, API-avain, PAT ja Logto M2M, palvelevat ensisijaista tarkoitusta todentaa käyttäjän tai sovelluksen pääsy tiettyyn palveluun tai resurssiin. Ne toimivat tunnuksina, jotka todistavat pyyntöä esittävän pyytäjän identiteetin, ja niitä käytetään yleensä CLI-komennoissa tai taustapalveluiden välisissä viestintäskenaarioissa.

2. Turvatoimenpiteet#

• Kaikkia näitä kolmea todennusmenetelmää tulisi käsitellä turvallisuus mielessä. Kehittäjien on varmistettava turvallinen tallennus ja siirto luvattoman pääsyn estämiseksi.

Erot#

1. Käyttäjäkonteksti#

• API-avain ei tunnista päätekijää, eikä anna mitään valtuutustietoa. Siksi API-avaimia käytetään usein julkisten tietojen tai resurssien anonyymiin käyttöön. Kaikki palvelut eivät tue API-avainten käyttöä.
• PAT on käyttäjätunnuksia ja edustaa sinua, kun sitä käytetään API-resurssien pyyntöön. Joissakin järjestelmissä PAT:eilla ei ole lupaa käyttää tiettyjä palveluja. Esimerkiksi NuGet-pakettien julkaiseminen Azure Artifacts -syötteeseen.
• Logto M2M -tunnistetietoja voivat käyttää vain luotetut asiakkaat. Asiakkaan on oltava rekisteröity etukäteen, jotta se voidaan todentaa. Kun käytät Logto M2M -tunnistetietoja, se edustaa luotettua asiakasta eikä käyttäjää, joka sitä käyttää.

2. Käyttöoikeuksien hienojakoisuus#

• PAT ja Logto M2M -tunnistetiedot tarjoavat yleensä hienojakoisempaa valvontaa käyttöoikeuksissa verrattuna API-avaimiin, jolloin voidaan tarkasti hallita mitä toimintoja voidaan tehdä.

3. Tunnuksen muoto#

• API-avain ja PAT ovat yleensä läpinäkymättömiä merkkijonoja, yksinkertaisia.
• Käyttöoikeustunnukset, jotka myönnetään Logto M2M -mekanismin kautta, ovat yleensä JWT-muodossa.

4. Valtuutusprosessi#

• API-avain ja PAT ovat järjestelmän tuottamia läpinäkymättömiä merkkijonoja, eikä niihin liity todennusprosesseja. Esimerkiksi voit kutsua Google Cloud -kielen käsittely API:a näin:

• Logto M2M hyödyntää standardia OAuth 2.0 -asiakastunnistetietojen virtausta. Jokaisella asiakkaalla on oltava pari asiakastunnusta ja salaisuus etukäteen, joilla asiakas voi myöhemmin vaihtaa käyttöoikeustunnuksen. Asiakas käyttää sitten käyttöoikeustunnusta API-resurssien käyttöön.

Milloin käyttää mitä#

API-avain#

• Palvelunvälinen viestintä: API-avaimet ovat sopivia skenaarioissa, joissa sovellusten on kommunikoitava API:eiden kanssa suoraan CLIs:n kautta. Esim. Kutsutaan OpenAI API:eja.
• Julkiset API:t: Kun API:eita avataan julkiseen käyttöön, API-avaimet tarjoavat suoraviivaisen pääsynhallinnan menetelmän.
• Yksinkertaistettu asennus: Nopea ja yksinkertainen todennustarve, erityisesti kehitysvaiheessa. Toisin kuin Logto M2M, API-avaimet eivät vaadi asiakkaan rekisteröintiä etukäteen, eivätkä ne tarvitse vaihtaa käyttöoikeustunnusta, vaan sinun tarvitsee vain lisätä API-avaimesi pyyntöösi ja se vain toimii.

Henkilökohtainen käyttötunnus (PAT)#

• Käyttäjäkohtaiset toiminnot: Kun sovelluksen on suoritettava käyttäjän puolesta toimintoja.
• Hienojakoinen pääsyn valvonta (käyttäjä): Kun vaaditaan tarkkaa kontrolointia toiminnosta, joka käyttäjä voi suorittaa.

Logto kone-keinokone (Logto M2M)#

• Turvallisuus: Logto M2M on ihanteellinen skenaarioihin, joissa vain luotetut asiakkaat saavat käyttää taustapalveluita.
• Hienojakoinen pääsyn valvonta (asiakas): Kun vaaditaan tarkkaa kontrolointia toiminnosta, jonka sovellus voi suorittaa.

Päätös#

Yhteenvetona, valinta API-avainten, PAT:iden tai Logto M2M:n välillä riippuu sovelluksesi erityisvaatimuksista, koskeeko se käyttäjäspesifejä toimintoja, koneiden välistä viestintää tai niiden yhdistelmää. Arvioi turvallisuus- ja toiminnallisuustarpeet sopivimman todennusmenetelmän määrittämiseksi käyttötapauksellesi.

Logto M2M -mekanismi mahdollistaa käyttäjille käyttöoikeuksien hienojakoisen kontrolloinnin RBAC:n (roolipohjaisten käyttöoikeuksien hallinta) ominaisuuksien avulla. Suunnittelemme myös API-avainten ja PAT:ien tukemista lähitulevaisuudessa. Pysykää kuulolla ominaisuuspäivityksiämme!