Tässä artikkelissa tarkastellaan OAuth 2.0 -tokenin introspektiota, menetelmää, joka sallii suojatun resurssin kysyä valtuutuspalvelimelta tokenin metatietoja ja määrittää, onko käyttöoikeus- tai päivitystoken voimassa.
OAuth 2.0 -tokenin introspektio määrittää menetelmän, joka sallii valtuutetun suojatun resurssin kysyä valtuutuspalvelimelta tiettyyn tokeniin (joko käyttöoikeus- tai päivitystokeniin), jonka OAuth-asiakas on antanut, liittyvät metatiedot. Perustuen tietyn tokenin metatietoihin, se sallii resurssin omistajan pääsyn suojattuun resurssiin.
Nämä metatiedot sisältävät:
Tokenin introspektio mahdollistaa suojatun resurssin kysyä näitä tietoja riippumatta siitä, sisältyvätkö ne itse tokeniin.
On olemassa kahdenlaisia käyttöoikeustokeneita koodausmenetelmästä riippuen:
Omaksi säilöttyjen tokenien osalta valtuutukseen liittyvät metatiedot voidaan lukea suoraan käyttöoikeustokenista. Tunnistepohjaisten tokenien osalta on kuitenkin käytettävä valtuutuspalvelimen tokenin introspektio-ominaisuutta metatietojen vahvistamiseen/hakemiseen.
Tunnistepohjaisten käyttöoikeustokenien käyttö edellyttää tarkastuspyyntöä valtuutuspalvelimelle verkkopyynnön kautta. Tätä varten on olemassa standardiprotokolla nimeltä OAuth 2.0 Token Introspection (RFC 7662).
Suojattu resurssi lähettää tokenin valtuutuspalvelimen introspektiopäätteeseen ja saa vastauksena JSON-objektin, joka sisältää tokenin parametrit.
Huomaa, että introspektiopyyntöjä ei voi käynnistää mielivaltaisesti; niiden on täytettävä jokin seuraavista ehdoista:
Tämän erityisen vuorovaikutuksen seurauksena suojattu resurssi toimii OAuth-asiakkaana ja valtuutuspalvelin suojattuna resurssina.
Alla on esimerkki introspektiopyynnöstä, jossa suojattu resurssi todentaa käyttämällä asiakastunnusta ja asiakassalaisuutta, jotka saatiin rekisteröitymällä OAuth-asiakkaaksi valtuutuspalvelimelle.
Alla on esimerkki introspektiopyynnöstä, joka käyttää suoraan käyttöoikeustokenia. Käyttöoikeustoken voidaan hakea suoraan /token -päätteestä käyttämällä rekisteröidyn kone-kone-sovelluksen tunnuksia ja client_credentials -ponnistusta.
Tärkein parametri on active, joka on totuusarvo. Jos true, se osoittaa, että token on voimassa, ja JSON-objekti sisältää muita tokenin tietoja, kuten laajuusarvot. Jos false, token on joko virheellinen tai vanhentunut, ja suojatun resurssin on palautettava 401 Unauthorized -vastaus invalid_token -virhekoodin kanssa.
Tässä on esimerkki vastauksesta voimassa olevalle tokenille:
Lukuun ottamatta active, joka on pakollinen, kaikki muut parametrit ovat vapaaehtoisia.
Suojattu resurssi voi käyttää näitä lisäkenttiä määrittääkseen käyttöoikeudet, samalla tavalla kuin se käyttäisi ja vahvistaisi JWT-käyttöoikeustokenin.