Yhdistämällä pisteet: Syvällinen tutkimus OIDC-resurssin ja JWT-pääsytokeneiden välisestä suhteesta

Taustaa#

Aiemmassa istunnossa esittelimme OpenID Connect (OIDC) -protokollan, päivitystokenit, pääsytokenit ja ID-tokenit, jotka ovat välttämättömiä komponentteja vahvan autentikoinnin rakentamisessa sovellukseesi. Kuitenkin yhteisössämme herää edelleen kysymyksiä, ja eräs toistuva kysymys kuuluu: "Miksi pääsytokeni ei ole JWT?”

Niille, jotka ovat uusia tämän asian parissa tai tarvitsevat kertausta, tämä blogikirjoitus pyrkii valaisemaan OIDC-resurssi-indikaattoreiden ja niiden roolin pääsytokeneiden hankinnassa.

OIDC-resurssin ymmärtäminen#

Jos olet tuttu OAuth 2.0 protokollan kanssa, termi “resurssi” pitäisi soittaa kelloa. Koska OIDC on rakennettu OAuth 2.0:n päälle, se perii tämän saman käsitteen.

"Resurssi" tai "suojattu resurssi" on edustama entiteetti, johon asiakassovellus haluaa päästä tunnistetun käyttäjän puolesta. Tämä voisi olla käyttäjätiedot, palvelimen API:t tai muu data, jonka palvelimesi on auktorisoinut.

Protokollan mukaan resurssi on parametrina valtuutuspalvelimelle lähetettävissä pyynnöissä. Se on arvo, joka on esitetty absoluuttisena URI:na, kuten https://my-company.com/api. Se toimii resurssin tunnisteena, joka voi vastata verkko-osoitettavaa sijaintia tai jopa ainutlaatuista mutta kuvitteellista URI:ta.

Logtossa voit luoda "API-resurssin" "Järjestelmänvalvojan konsoli → API-resurssit" -sivun kautta. Voit tutustua tähän dokumentaatioon saadaksesi lisätietoja.

JWT-pääsytoken#

JWT (JSON Web Token) muotoista pääsytokenia annetaan vain silloin, kun "resurssi"-parametri on määritetty pääsytokenia pyydettäessä, ja se sisältää joukon vaatimuksia, jotka voit purkaa ja varmistaa esimerkiksi varmistaaksesi tokenin eheyden ja käyttäjän oikeudet.

Tämä "resurssi" tulee sitten yhdeksi aud tokenin vaatimuksista JWT:ssä, ja se osoittaa tokenin suunnatun yleisön. Katso RFC-7519.

Niinpä suhde tulee selväksi:

• Määritä resurssi-indikaattori pyytäessäsi JWT-tokenia.
• Resurssi-indikaattori on linjassa aud tokenin vaatimuksen kanssa.
• Kun teet API-pyyntöjä, JWT-pääsytoken on sisällytettävä kantajatoken-otsakkeeseen. API-palvelimesi pitäisi purkaa ja varmistaa aud vaatimus ja muut oikeuksiin liittyvät vaatimukset turvatakseen API-pyynnön.
• Jokainen pääsytoken vastaa yhtä resurssia. Jos sinulla on useita API-resursseja rekisteröity eri URI:lla, pyydä erilliset pääsytokenit kullekin.

🤔 Mutta mitä jos asiakas ei määritä resurssia pyytäessään pääsytokenia?

Peitetty pääsytoken#

Logton tapauksessa, jos resurssi-indikaattoria ei ole määritetty pääsytokenia pyydettäessä, valtuutuspalvelin olettaa sen olevan OIDC /userinfo-päätepistettä varten ja näin ollen peitetty pääsytoken myönnetään, jota asiakas voi myöhemmin käyttää pyytämään käyttäjäprofiilitietoa, kuten käyttäjätunnusta, nimeä, sähköpostia jne., OIDC käyttäjäinfo-päätepisteestä.

Mikä tahansa Logton SDK:ssa voit hankkia tällaisen tokenin, jos kutsut getAccessToken() tai suoraan pyydät OIDC-tokenipäätettä määrittämättä resurssi-parametria.

Huomaa, että tämä peitetty pääsytoken ei sovi omien API-resurssipyynnöksiesi käyttöön, koska sitä ei voi varmistaa ilman pyyntöä OIDC-palvelimelle.

Yhteenvetona#

OIDC-resurssit määrittelevät tietyt tiedot tai palvelut, joihin asiakassovellus haluaa päästä käyttäjän puolesta, ja JWT-pääsytokenit toimivat turvallisena keinona tähän pääsyyn. "Aud"-vaatimus JWT-pääsytokenissa on linjassa resurssi-indikaattorin kanssa, mikä auttaa palvelimia varmistamaan oikeudet asiakaspyyntöjen yhteydessä.

Logtossa peitetty pääsytoken on tarkoitettu ainoastaan käyttäjäprofiilitietojen hakemiseen OIDC käyttäjäinfo-päätepisteestä, kun taas asiakkaat voivat pyytää useita pääsytokeneita, joista kukin on omistettu tietylle resurssille.

Toivomme, että tämä blogikirjoitus selventää epäilyksiä ja yhdistää pisteitä sinulle. Kerrothan meille ajatuksiasi.