Token vaihto OAuth/OIDC:ssa

Token-vaihto esiteltiin RFC 8693 -julkaisussa, ja se on OAuth-laajennus, joka sallii luotettujen asiakkaiden vaihtaa olemassa olevan tokenin uuteen, eri ominaisuuksilla tai rajoilla. Tämä mekanismi on erityisesti hyödyllinen palvelulle, sovellukselle tai loppukäyttäjälle, joka haluaa saada normaalin OAuth-pääsytokenin valmiiksi valtuutetun tokenin kautta ilman tarvetta käydä läpi koko OAuth-prosessia.

Vertailu valtuutuskoodin kanssa#

Ensiksi katsotaan OAuth-valtuutuskoodin prosessia, joka on yleisin tapa hankkia pääsytokeneita.

Ja tämä on tokenin vaihtoprosessi:

Uudelleenohjaus#

Suurin ero on, että valtuutuskoodiprosessissa asiakassovellus ohjaa käyttäjän valtuutuspalvelimelle hankkimaan pääsytokenin. Tokenin vaihdossa asiakassovellus voi vaihtaa tokenin valtuutuspalvelimen kanssa ilman, että käyttäjää tarvitaan ohjaamaan uudelleen.

Tämä johtuu siitä, että valtuutuskoodiprosessissa asiakassovellus ei ole "luotettu" ja sen täytyy tietää käyttäjän tunnistetiedot saadakseen pääsytokenin. Tokenin vaihdossa asiakassovelluksen on jo hankittava token käyttäjältä, ja valtuutuspalvelin vahvistaa tokenin ja myöntää uuden.

Tokenin myöntäjä ja tokenin vaihto palvelu#

Tokenin vaihtoprosessissa "Auth Server" on nyt kaksi osallistujaa:

1. Tokenin myöntäjä: myöntää aihekentän tokenin asiakassovellukselle.
2. Tokenin vaihtopalvelu: vahvistaa aihekentän tokenin ja myöntää uuden tokenin asiakassovellukselle.

Tokenin vaihtopalvelu on sama kuin "Auth Server" valtuutuskoodiprosessissa, ja tokenin myöntäjä voi olla kolmannen osapuolen identiteetin tarjoaja tai erotettu "Auth Serverista" erillisenä palveluna.

Milloin käyttää tokenin vaihtoa?#

Tokenin vaihtoprosessi voidaan suorittaa ilman käyttäjän vuorovaikutusta, mikä on hyödyllistä seuraavissa tilanteissa:

• Impersonaatio: Sallii palveluiden (esim. taustamikropalvelut) tai hallinnon käyttäjien suorittaa toimintoja käyttäjän puolesta paljastamatta koko käyttäjän tunnistetietoja.
• Automaatio: Sallii luotettujen palveluiden suorittaa toimenpiteitä automaattisesti ilman manuaalista väliintuloa tai tehdä automatisoitua testausta.
• Integraatio muiden identiteetin tarjoajien kanssa: Kääntää tokeneita eri identiteettijärjestelmien välillä ylläpitämään saumaton käyttäjäkokemus ja hallitsemaan oikeuksia tehokkaasti, yksi yleinen skenaario on kääntää SSO-token tokeniksi alavirran palvelulle.
• Migraatio: Siirtää tokeneita yhdestä valtuutuspalvelimesta toiseen, esimerkiksi perintöjärjestelmästä moderniin OAuth/OIDC-yhteensopivaan järjestelmään.

Tokenin vaihtoprosessi#

Uuden pääsytokenin hankkiminen on yleisin tapaus, otetaan tämä esimerkkinä. Tokenin vaihtoa ei ole rajoitettu vain pääsytokeneihin, vaan sitä voidaan käyttää myös muiden token-tyyppien, kuten uusimistokenin, ID-tokenin, jne., myöntämiseen.

Asiakassovellus#

Tokenin vaihdon suorittamiseen tarvitaan rekisteröity asiakassovellus valtuutuspalvelimen kanssa.

Ja asiakassovelluksella pitää olla subject_token ennen tokenin vaihtoprosessin aloittamista, tämä token myönnetään yleensä valtuutuspalvelimen tai luotetun kolmannen osapuolen identiteetin tarjoajan toimesta. Kun tämä token on käytössä, asiakassovellus voi nyt olla "luotettu" vaihtamaan tokeneita ilman käyttäjän tunnistetietoja ja vuorovaikutusta.

Tokenin vaihtopyyntö#

Asiakas lähettää pyynnön valtuutuspalvelimen tokenin päätepisteeseen vaihtaakseen olemassa olevan tokenin. Tämä sisältää subject_token (vaihdettava token) ja halutessaan kohdeyleisön, reunaehdon ja token-tyypin.

1. grant_type: PAKOLLINEN. Tämän parametrin arvo on oltava urn:ietf:params:oauth:grant-type:token-exchange, mikä osoittaa, että tokenin vaihto suoritetaan.
2. subject_token: PAKOLLINEN. Käyttäjän PAT.
3. subject_token_type: PAKOLLINEN. Tämän parametrin tyyppi subject_token -parametrissa. Yleinen arvo on urn:ietf:params:oauth:token-type:access_token, mutta se voi vaihdella, riippuen vaihdettavasta tokenista.
4. resource: VALINNAINEN. Resurssi-indikaattori, joka auttaa määrittämään pääsytokenin kohderesurssin.
5. audience: VALINNAINEN. Pääsytokenin yleisö, osoittaa tokenin tarkoitetut vastaanottajat, valtuutuspalvelin voi käyttää resource-arvoa, jos audience ei ole määritelty.
6. scope: VALINNAINEN. Pyydetyt reunaehdot.

Pyyntö myös sisältää asiakastiedot, jotka voidaan enkoodata Basic Auth -otsikkona tai lähettää lomakedatana.

Tässä on esimerkki pyynnöstä:

Tokenin vaihto Logtossa#

Logto tukee tokenin vaihtoa oletuksena, mukaan lukien impersonaatio ja henkilökohtaiset pääsytokenit.