SAML2 vs JWT: OpenID Connect 3. osa mõistmine

OpenID Connecti mõistmise 1. ja 2. osas tutvustati põhikontseptsioone ja esimest autentimisvoogu (Authorization Code Grant Flow). 3. osas vaatleme järelejäänud autentimisvooge (kaudne voog ja hübriidvoog) ning mõnda muud OIDC spetsifikatsiooni funktsiooni.

Kaudne voog (OIDC v1.0 spetsifikatsioon, jaotis 3.2): See sarnaneb OAuth2 spetsifikaadi kaudse toetusega, kuid laiendab tegelikult OIDC autoriseerimiskoodi voogu. See tagastab ID-tokeni ja juurdepääsu tokeni otse kasutajaagendile autentimisvastuse osana autoriseerimise lõpp-punktile. Kaudset voogu kasutavad RP-d võivad olla ainult avalikud kliendid (kliendi saladust pole).

Päringu parameetril return_type autoriseerimise lõpp-punktile võib olla üks kahest väärtusest: id_token ja „id_token token”. Esimene väärtus vastab lõppkasutaja autentimise stsenaariumile; teine ​​väärtus toetab RP lõppkasutaja autentimist ja ressursiserverile juurdepääsu RP.

Esimese vastuse_tüübi väärtuse (id_token token) jaoks toimitakse järgmiselt.

Kaudne voog SSO- ja API-kõnega (response_type = “id_token token”)

Nii nagu autoriseerimiskoodi voog, käivitab lõppkasutaja brauseri (või mõne muu kasutajaagendi), mis esitab rakendusele (abikõlblik osapool) esmase päringu. Uuringupool (RP) võtab taotluse kinni ja tuvastab, et see ei kuulu autentitud seanssi; nii vastab RP päringule HTTP-suunamisega OP-sammule (A). Autoriseerimise lõpp-punktile saadetud autentimistaotlus näeb välja järgmine:

GET / oidc / lubada?
    response_type = id_token% 20token
    & klient_id = s6BhdRkqt3
    & redirect_uri = https% 3A% 2F% 2Fclient.example.org% 2Fcb
    & ulatus = avatud% 20profiil
    & riik = af0ifjsldkj
    & nonce = n-0S6_WzA2Mj HTTP / 1.1
  Host: server.example.com

OP suunab kasutajaagendi sisselogimise töövoogu, mida teenindab toiming (B). Autentimise toimimise üksikasjad jäävad OIDC spetsifikaadi reguleerimisalast välja. Autentimise töövoog võib sisaldada lõppkasutaja võimalust anda RP-le nõusolek lõppkasutaja omanduses olevate ressursside kasutamiseks. Pärast edukat autentimist saadab operatsioonisüsteem operaatori HTTP ümbersuunamise vastuse, et tagastada kasutaja autoriseerimise lõpp-punkti. OP vastab autentimisvastusega, mis näeb välja umbes järgmine - samm (c):

HTTP / 1,1 302 leitud
  Asukoht: https://client.example.org/cb#
    access_token = SlAV32hkKG
    & token_type = kandja
    & id_token = eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso
    & aegub_in = 3600
    & riik = af0ifjsldkj

Erinevalt autoriseerimiskoodi voo vastusest sisaldab see vastus nii ID-tunnust kui ka juurdepääsuluba. Niisiis näeb kasutajaagent juurdepääsu juurdepääsu tunnust ja ID-tunnust - see kujutab endast uut potentsiaalsete rünnakute pindala, mida esimese uuritud voo korral pole olemas. Samuti märkate, et see ümbersuunamise URL läbib märgid (ja muu teabe) URI fragmendis; seega on vaja, et kasutajaagent (või brauseris töötav kood Javascript) sõelub URI fragmendi ja ekstraheerib žetoonid, et need kliendile edastada (lisateabe saamiseks vt OIDC spetsifikatsiooni jaotist 15.5.3).

Kasutajaagent saadab ümbersuunamistaotluse (koos ekstraheeritud märkide ja muu teabega) RP-le (kui on olemas serveripoolne komponent). Taotlus näeb välja järgmine: (spetsifikaadi jaotise 15.5.3 järgi):

POST https://client.example.org/cb
    access_token = SlAV32hkKG
    & token_type = kandja
    & id_token = eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso
    & aegub_in = 3600
    & riik = af0ifjsldkj

RP võtab taotluse kinni ja eraldab märgid (ja muud parameetrid). RP valideerib autentimisvastuse vastavalt OIDC spetsifikatsiooni jaotises 3.2.2.8 kirjeldatud sammudele (sealhulgas jaotises 3.2.2.11 kirjeldatud ID-tunnuse sammudele - samm (D)) ja valikuliselt, ehkki tungivalt julgustatud, juurdepääsutunnuse sammudele, mida on kirjeldatud Jaotis 3.2.2.9 - etapp (E)).

Järgmisena, kui RP vajab täiendavaid nõudeid, võib ta pöörduda OP-i UserInfo lõpp-punkti poole, et saada neid vastavalt eelpool kirjeldatule - sammud (F) ja (G). Pange tähele, et RP-l on ID-tunnus ja see võib sisaldada kõiki nõudeid, mille UserInfo lõpp-punkt võib tagasi saata. Siin on asjakohane ka kommentaar viimase voo kirjelduse selle sammu kohta.

Järgmisena pääseb RP juurde ressursside serveris asuvale ressursile (nimetagem seda API-pakkuja API-ks), helistades API-le, kasutades autoriseerimise päises asuvat juurdepääsu tunnust, nagu me oleme varem uurinud - samm (H). Kommentaarid selle osa kohta jaotises Autoriseerimiskoodide vool kehtivad siin.

Ressursiserver võtab taotluse kinni ja eraldab juurdepääsu tokeni. Juurdepääsumärki valideerib ressursiserver - samm (I). Selle osa kommentaarid autoriseerimiskoodi voolu jaotises kehtivad siin.

Lõpuks saab ressursiserver edastada saadud juurdepääsuloa kasutaja infole lõpp-punktile, et saada ID-tunnus koos lõppkasutaja asjakohaste (ja lubatud) nõuetega lõpptarbijale - sammud (J) ja (K). API-päringu töötlemine võib jätkuda ja vastuse saab tagastada RP-le (kes tegutseb selle stsenaariumi korral API-tarbijana).

Stsenaariumi, millest me just läbi kõndisime, kirjeldame järgnevas diagrammis.

Teise vastuse_tüübi väärtuse (id_token) jaoks toimitakse järgmiselt.

Kaudne voog SSO-ga (response_type = id_token)

Nii nagu esimene kaudne voog, käivitab lõppkasutaja brauseri (või muu kasutajaagendi), mis esitab rakendusele esialgse taotluse. RP võtab taotluse kinni ja tuvastab, et see ei kuulu autentitud seanssi; nii vastab RP päringule HTTP ümbersuunamisega OP-i autoriseerimise lõpp-punktile - samm (A). Autoriseerimise lõpp-punktile saadetud autentimistaotlus näeb välja järgmine:

GET / oidc / lubada?
    response_type = id_token
    & klient_id = s6BhdRkqt3
    & redirect_uri = https% 3A% 2F% 2Fclient.example.org% 2Fcb
    & ulatus = avatud% 20profiil% 20email
    & nonce = n-0S6_WzA2Mj
    & olek = af0ifjsldkj HTTP / 1.1
  Host: server.example.com

OP suunab kasutajaagendi sisselogimise töövoogu, mida teenindab toiming (B). Nagu alati, jäävad autentimise teostamise üksikasjad OIDC spetsifikaadi kohaldamisalast välja. Sarnaselt muude autentimisvoogudega võib sisselogimise töövoog hõlmata lõppkasutajale võimalust anda RP-le nõusolek lõpptarbijale kuuluvate ressursside osas. Pärast edukat autentimist saadab operatsioonisüsteem HTTP ümbersuunamistaotluse, et naasta autoriseerimise lõpp-punkti. OP reageerib autentimisvastusega, mis näeb välja umbes järgmine - samm ©:

HTTP / 1,1 302 leitud
  Asukoht: https://client.example.org/cb#
    id_token = eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso
    & riik = af0ifjsldkj

See vastus sisaldab ID-tunnust. Nii näeb kasutajaagent ID-tunnust - see kujutab potentsiaalsete rünnakute jaoks sarnast pinda, mida nägime kaudses voo stsenaariumis. Te jälle märkate, et see ümbersuunamise URL läbib ID-tunnuse URI fragmendis; seega on vaja, et kasutajaagent (või brauseris töötav kood Javascript) sõelub URI fragmendi ja ekstraheerib ID-tokeni, et see kliendile edastada (lisateabe saamiseks vt OIDC spetsifikatsiooni jaotist 15.5.3).

Kasutajaagent saadab ümbersuunamistaotluse (koos ekstraheeritud ID-märgiga) RP-le (kui on olemas serveripoolne komponent). Taotlus näeb välja järgmine: (spetsifikaadi jaotise 15.5.3 järgi):

POST https://client.example.org/cb
    id_token = eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso
    & riik = af0ifjsldkj

RP võtab taotluse kinni ja eraldab ID-loa. RP valideerib autentimisvastuse vastavalt OIDC spetsifikatsiooni jaotises 3.2.2.8 kirjeldatud sammudele (sealhulgas ID tokeni etapid, mida on kirjeldatud jaotises 3.2.2.11 - samm (D)).

Järgmisena, kui RP vajab täiendavaid nõudeid, võib ta pöörduda OP-i UserInfo lõpp-punkti poole, et saada neid vastavalt eelpool kirjeldatule - sammud (E) ja (F). Siin on asjakohane ka kommentaar viimase voo kirjelduse selle sammu kohta.

Need sammud on toodud alljärgnevas diagrammis.

Erinevused

Oluline erinevus kaudse ja kahe muu voo vahel on see, et RP (kliendi) autentimiseks puudub tugi. See on oluline roll tema rollis looduslikes mobiilirakendustes ja üheleheliste rakenduste (SPA) kasutamise juhtumites.

Kaudne voog tagastab žetoonid märgise lõpp-punktist kasutajaagendile ümbersuunamise URI URI fragmentidena, mitte päringuparameetritena.

Teine erinevus on see, et kaudses voos pole värskendusmärkide värskendamine lubatud, mistõttu selle jaotise näidetes ei kuvata värskendamisluba kuskil.

Hübriidvool (OIDC v1.0 spets., Punkt 3.3): see vool ühendab ülejäänud kahe voo aspekte. See pakub paindlikkust, et võimaldada rakenduse esi- ja tagaküljel saada oma kohaldatavad märgid. Seda ei kasutata kuigi sageli, kuid selle täielikkus on lisatud.

Selle asemel, et läbida hübriidvoo kolmest võimalikust variatsioonist sama detailsusega nagu autoriseerimiskoodi voog ja kaudne voog, kasutagem autoriseerimiskoodide andmise lähtepunktina interaktsiooni lähtepunktina autoriseerimiskoodi andmist. Seejärel kutsuge esile erinevused selle ja hübriidvoolu vahel - see on, kuidas spec eristab seda.

Autoriseerimise lõpp-punktiga suhtlemisel on järgmised erinevused:

  • Parameetril response_type peab olema üks selles artiklis varem kirjeldatud väärtustest (“kood id_token”, “code token” või “code id_token token”).
  • Autentimisvastus on sama, mida kasutatakse kaudses lõpp-punktis, välja arvatud:

access_token: see on OAuth 2.0 juurdepääsu luba. See tagastatakse, kui response_type väärtus sisaldab märki. Tagastatakse ka parameeter token_type.

id_token: OIDC ID-tunnus. See tagastatakse, kui response_type väärtus sisaldab „id_token”.

kood: OIDC autoriseerimiskood. See tagastatakse alati, nagu näitavad kõik võimalikud koodiga sisestusväärtused return_type.

  • Kõiki autentimis- või nõusolekufaasides ilmnenud vigu käideldakse samamoodi nagu autoriseerimiskoodi voogu ja autoriseerimisserver PEAB tagastama ümbersuunamise URI fragmendikomponendi vea autoriseerimisvastuse, nagu on määratletud OAuth 2.0 punktis 4.2.2.1. [RFC6749] ja OAuth 2.0 mitme vastuse tüübi kodeerimise tava [OAuth.Responses], kui pole määratud teistsugust reageerimisrežiimi. ”
  • RP valideerib autentimisvastuse vastavalt OIDC spetsifikatsiooni jaotisele 3.3.2.8.

Token Endpoint puhul toimub interaktsioon jälle samal viisil nagu autoriseerimiskoodi andmise voog (vastavalt OIDC spetsifikatsiooni jaotisele 3.3.3), välja arvatud järgmised erandid:

  • Tokeni lõpp-punktist tagastatud ID-tokeni sisu on sama, mis autoriseerimise lõpp-punkti tagastatud ID-toki sisu.
  • Kui mõlemast otspunktist antakse ID-tunnus, lisab jaotis 3.3.3.6 lisanõuded, mis peavad olema täidetud.
  • Märgi lõpp-punktist tagastatud märk peab olema kinnitatud samamoodi nagu autoriseerimiskoodi voog.
  • Kui pääsutunnus tagastatakse mõlemast otspunktist, võivad märgid olla samad või erinevad. See võib olla kasulik olukorras, kus turbeatribuudid mõjutavad kasutajaliidese elementide kuvamist.

Me ei hakka siin selle voolu osas üksikasjalikumalt uurima, kuid kui vajate lisateavet, võib enamiku üksikasjadest järeldada autoriseerimiskoodi andmise voo ja varasema implitseeritud voo aruteludest.

Sisselogimise algatamine kolmandalt osapoolelt (IdP-algatatud sisselogimine)

Kui tuletate meelde varasematest SAML2 kasutamise juhtumitest, arutasime teenusepakkuja (SP) - algatatud sisselogimise ja identiteedi pakkuja (IdP) - algatatud sisselogimist. Kõik seni arutatud autentimisvood esindavad SP-i algatatud sisselogimisi. OIDC spetsifikatsiooni 4. jaos on määratletud, kuidas OpenID pakkuja või mõni muu kolmas osapool saab sisselogimisi algatada.

Sisselogimisprotsessi algatamiseks peab OP saatma sisselogimise algatamise lõpp-punkti RP-l järgmiste parameetritega:

iss: Vajalik. See on OP väljastaja identifikaator, kellele RP peaks autentimistaotluse saatma.

login_hint: valikuline. See on vihje nime (vormingu / tüübi) kohta, mille lõppkasutaja sisestaks. See võimaldab sisselogimise töövoodil kasutajanime eeltäita.

target_link_uri: valikuline. See on URL, mida RP-l palutakse suunata kasutajale pärast edukat autentimist.

Lisateavet leiate OIDC spetsifikatsioonist.

Selle kirjutamise ajal pole OIDC IdP-initsialiseeritud (kolmanda osapoole algatatud) sisselogimine veel vabas looduses nii tavaline. Kuid kuna OIDC võetakse laialdasemalt kasutusele, on vaja täiustatud kasutusjuhtude toetamist.

Sarnaselt võib seda funktsiooni RP kasutada ka mitme operatsioonisüsteemi (identiteedipakkujate) toetamiseks.

Väljalogimise tugi

OIDC seansihalduse spetsifikatsioon määratleb seansihaldus- ja väljalogimisfunktsioonid. See spetsifikatsioon on valikuline; nii et kinnitage, et OP ja RP toetavad seda. Selles postituses ei käsitleta OIDC väljalogimise kohta lisateavet, kuid teemat käsitletakse siin.

Kokkuvõte

Sellega lõpetame meie arutelu OIDC üle.

Selle seeria järgmises postituses vaatame lõpuks JWT kasutusjuhtumeid, kasutades selles sarjas JWT, OAuth2 ja OIDC kohta teada saadud teavet.

Jäta kommentaarid ja küsimused allpool.