SAML2 vs JWT: Izpratne par OpenID Connect 3. daļu

Izpratnes OpenID Connect 1. un 2. daļā tika ieviestas pamatkoncepcijas un pirmā autentifikācijas plūsma (Authorization Code Grant Flow). 3. daļā mēs aplūkojam atlikušās autentifikācijas plūsmas (netiešā plūsma un hibrīda plūsma) un dažas citas OIDC specifikācijas funkcijas.

Netiešā plūsma (OIDC v1.0 specifikācija, 3.2. Sadaļa): Tas ir līdzīgs netiešajai dotācijai no OAuth2 specifikācijas, taču faktiski tā paplašina OIDC autorizācijas koda plūsmu. Tas atdod ID marķieri un piekļuves pilnvaru tieši lietotāja aģentam kā daļu no autentifikācijas atbildes uz autorizācijas galapunktu. RP, kas izmanto netiešo plūsmu, var būt tikai publiski klienti (klienta noslēpuma nav).

Vaicājuma parametram return_type autorizācijas galapunktam var būt viena no divām vērtībām: id_token un “id_token token”. Pirmā vērtība atbilst galalietotāja autentifikācijas scenārijam; otrā vērtība atbalsta RP gala lietotāja autentifikāciju un RP piekļuvi Resursu serverim.

Pirmajai atbildes_ veida vērtībai (id_token token) tiek veiktas šādas darbības.

Netieša plūsma ar SSO un API zvanu (response_type = “id_token token”)

Tāpat kā autorizācijas koda plūsma, tiešais lietotājs atvērs pārlūku (vai citu lietotāja aģentu), kas sākotnēji pieprasa lietojumprogrammai (paļāvīgā puse). Atbildīgā puse (RP) pārtver pieprasījumu un atklāj, ka tas nav daļa no autentificētās sesijas; tātad RP uz pieprasījumu atbild ar HTTP pāradresāciju uz OP darbību (A). Autentifikācijas pieprasījums, kas nosūtīts autorizācijas galapunktam, izskatās šādi:

GET / oidc / atļaut?
    response_type = id_token% 20token
    & klienta_id = s6BhdRkqt3
    & redirect_uri = https% 3A% 2F% 2Fclient.example.org% 2Fcb
    & darbības joma = atvērts% 20 profils
    & valsts = af0ifjsldkj
    & nonce = n-0S6_WzA2Mj HTTP / 1.1
  Saimnieks: server.example.com

OP novirzīs lietotāja aģentu uz pieteikšanās darbplūsmu, kuru apkalpo OP darbība (B). Sīkāka informācija par to, kā darbojas autentifikācija, nav iekļauta OIDC specifikācijā. Autentifikācijas darbplūsma var ietvert iespēju galalietotājam dot piekrišanu RP piekļūt resursiem, kas pieder galalietotājam. Pēc veiksmīgas autentifikācijas OP nosūtīs HTTP novirzīšanas atbildi, lai atgrieztu lietotāju autorizācijas beigu punktā. OP atbildēs ar autentifikācijas atbildi, kas izskatās apmēram šādi: (c) solis:

Atrasts HTTP / 1.1 302
  Atrašanās vieta: https://client.example.org/cb#
    access_token = SlAV32hkKG
    & token_type = nesējs
    & id_token = eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso
    & derīguma termiņš_in = 3600
    & valsts = af0ifjsldkj

Atšķirībā no atbildes no autorizācijas koda plūsmas, šajā atbildē ir gan ID marķieris, gan piekļuves marķieris. Tātad, lietotāja aģents varēs redzēt piekļuves pilnvaru un ID marķieri - tas parādīs jaunu potenciālo uzbrukumu laukumu, kas nepastāv ar pirmo mūsu pārbaudīto plūsmu. Jūs arī pamanīsit, ka šis novirzīšanas URL nodod marķierus (un citu informāciju) URI fragmentā; tātad, lietotāja aģentam (vai pārlūkā darbinātam kodam, Javascript) ir jā parsēra URI fragments un jāizņem marķieri, lai tos nodotu klientam (lai iegūtu vairāk informācijas OIDC specifikācijas 15.5.3. sadaļā).

Lietotāju pārstāvis nosūta novirzīto pieprasījumu (ar izvilktiem žetoniem un citu informāciju) RP (ja ir servera puses komponents). Pieprasījums izskatīsies šādi (saskaņā ar specifikācijas 15.5.3. Sadaļu):

POST https://client.example.org/cb
    access_token = SlAV32hkKG
    & token_type = nesējs
    & id_token = eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso
    & derīguma termiņš_in = 3600
    & valsts = af0ifjsldkj

RP pārtver pieprasījumu un izvelk marķierus (un citus parametrus). RP apstiprina autentifikācijas atbildi saskaņā ar OIDC specifikācijas 3.2.2.8. Iedaļā aprakstītajiem soļiem (ieskaitot ID marķiera darbības, kas aprakstītas 3.2.2.11. Iedaļā - solis (D)) un pēc izvēles, kaut arī to ļoti mudina, piekļuves marķiera darbības, kas aprakstītas 3.2.2.9. Sadaļa - solis (E)).

Pēc tam, ja RP ir vajadzīgas papildu pretenzijas, tas var sazināties ar OP's UserInfo galapunktu, lai tos iegūtu, kā aprakstīts iepriekš - (F) un (G) darbības. Ņemiet vērā, ka RP ir ID marķieris un tajā var būt visas pretenzijas, kuras var atgriezt UserInfo Endpoint. Šeit ir būtisks arī komentārs par šo darbību pēdējās plūsmas aprakstā.

Tālāk RP var piekļūt resursam Resursu serverī (sauksim to par API uz API nodrošinātāju), veicot zvanu uz API ar piekļuves marķieri autorizācijas galvenē, kā mēs esam izpētījuši iepriekš - (H). Šeit ir piemērojami komentāri par šo daļu sadaļā Atļaujas koda plūsma.

Resursu serveris pārtver pieprasījumu un iegūst piekļuves pilnvaru. Piekļuves marķieri apstiprina resursu serveris - solis (I). Šeit tiek komentēti komentāri par šo daļu sadaļā Atļaujas koda plūsma.

Visbeidzot, resursu serveris var nodot saņemto piekļuves marķieri UserInfo Endpoint, lai iegūtu ID marķieri ar atbilstošiem (un atļautiem) gala lietotāja pieprasījumiem - darbības (J) un (K). Var turpināt API pieprasījuma apstrādi, un atbildi var atgriezt RP (šajā scenārijā darbojas kā API patērētājs).

Scenārijs, kuru mēs tikko izgājām, ir aprakstīts sekojošajā diagrammā.

Otrajai response_type vērtībai (id_token) tiek veiktas šādas darbības.

Netiešā plūsma ar SSO (response_type = id_token)

Tāpat kā pirmā netiešā plūsma, galalietotājs atvērs pārlūku (vai citu lietotāja aģentu), kas iesniegs sākotnēju pieprasījumu lietojumprogrammai (RP). RP pārtver pieprasījumu un atklāj, ka tas nav daļa no autentificētās sesijas; tātad RP uz pieprasījumu atbild ar HTTP novirzīšanu uz OP autorizācijas galapunktu (A). Autentifikācijas pieprasījums, kas nosūtīts autorizācijas galapunktam, izskatās šādi:

GET / oidc / atļaut?
    response_type = id_token
    & klienta_id = s6BhdRkqt3
    & redirect_uri = https% 3A% 2F% 2Fclient.example.org% 2Fcb
    & darbības joma = openid% 20profile% 20email
    & nonce = n-0S6_WzA2Mj
    & state = af0ifjsldkj HTTP / 1.1
  Saimnieks: server.example.com

OP novirzīs lietotāja aģentu uz pieteikšanās darbplūsmu, kuru apkalpo OP darbība (B). Kā vienmēr, sīkāka informācija par to, kā tiek veikta autentifikācija, nav iekļauta OIDC specifikācijā. Tāpat kā citās autentifikācijas plūsmās, pieteikšanās darbplūsmā var iekļaut iespēju galalietotājam dot piekrišanu RP par resursiem, kas pieder galalietotājam. Pēc veiksmīgas autentifikācijas OP nosūtīs HTTP novirzīšanas pieprasījumu, lai atgrieztos autorizācijas beigu punktā. OP atbildēs ar autentifikācijas atbildi, kas izskatās apmēram šādi - © solis:

Atrasts HTTP / 1.1 302
  Atrašanās vieta: https://client.example.org/cb#
    id_token = eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso
    & valsts = af0ifjsldkj

Šajā atbildē ir ID marķieris. Tātad, lietotāja aģents varēs redzēt ID marķieri - tas parādīs līdzīgu potenciālo uzbrukumu virsmas laukumu, ko mēs redzējām pirmajā netiešās plūsmas scenārijā. Jūs atkal pamanīsit, ka šis novirzīšanas URL URI fragmentā nodod ID marķieri; tātad, lietotāja aģentam (vai pārlūkā darbināmam kodam, Javascript) ir jā parsēra URI fragments un jāizņem ID marķieris, lai to nodotu klientam (papildinformāciju skat. OIDC specifikācijas 15.5.3. sadaļā).

Lietotāju aģents nosūta novirzīto pieprasījumu (ar ekstrahētu ID marķieri) RP (ja ir servera puses komponents). Pieprasījums izskatīsies šādi (saskaņā ar specifikācijas 15.5.3. Sadaļu):

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

RP pārtver pieprasījumu un iegūst ID marķieri. RP apstiprina autentifikācijas atbildi saskaņā ar OIDC specifikācijas 3.2.2.8. Iedaļā aprakstītajiem soļiem (ieskaitot ID marķiera darbības, kas aprakstītas 3.2.2.11. Sadaļā - (D)).

Pēc tam, ja RP ir vajadzīgas papildu pretenzijas, tas var sazināties ar OP's UserInfo galapunktu, lai tos iegūtu, kā aprakstīts iepriekš - (E) un (F) darbība. Šeit ir būtisks arī komentārs par šo darbību pēdējās plūsmas aprakstā.

Šīs darbības ir aprakstītas sekojošajā diagrammā.

Atšķirības

Svarīga atšķirība starp netiešo plūsmu un pārējām divām plūsmām ir tā, ka RP (klienta) autentificēšanai netiek sniegts atbalsts. Tas ir nozīmīgs faktors, kas ietekmē tās lomu vietējās mobilajās lietojumprogrammās un vienas lapas lietojuma gadījumos.

Netiešā plūsma no marķiera gala punkta marķierus atdod lietotāja aģentam kā novirzīšanas URI URI fragmentus, nevis kā vaicājuma parametrus.

Vēl viena atšķirība ir tā, ka netiešā plūsmā nav atļauts atsvaidzināt pilnvaras, tāpēc šīs sadaļas piemēros atsvaidzināšanas pilnvara nav redzama.

Hibrīda plūsma (OIDC v1.0 spec, 3.3. Sadaļa): Šī plūsma apvieno pārējo divu plūsmu aspektus. Tas nodrošina elastību, ļaujot lietojumprogrammas priekšējai un aizmugurējai daļai saņemt savus pilnvaras. Tas netiek izmantots ļoti bieži, bet ir iekļauts pilnīguma dēļ.

Tā vietā, lai pārbaudītu katru no trim iespējamajām hibrīda plūsmas variācijām tikpat detalizēti kā autorizācijas koda plūsma un netiešā plūsma, par autorizācijas galapunkta mijiedarbības sākumpunktu izmantosim autorizācijas koda piešķīrumu. Pēc tam izsauciet atšķirības starp šo un hibrīdo plūsmu - tas ir veids, kā spec to izklāsta.

Mijiedarbībai ar autorizācijas parametru pastāv šādas atšķirības:

  • Paraugam response_type ir jābūt kādai no vērtībām, kas aprakstītas iepriekš šajā rakstā (“kods id_token”, “code token” vai “code id_token token”).
  • Autentifikācijas atbilde ir tāda pati kā netiešajā parametrā, izņemot:

piekļuves_zīme: Šis ir OAuth 2.0 piekļuves pilnvara. Tas tiek atgriezts, kad response_type vērtībā ir “marķieris”. Tiks atgriezts arī parametrs token_type.

id_token: OIDC ID marķieris. Tas tiek atgriezts, kad response_type vērtībā ir “id_token”.

kods: OIDC autorizācijas kods. Tas vienmēr tiek atgriezts, kā norāda visas iespējamās return_type vērtības, kas satur “kodu”.

  • Visas kļūdas, kas rodas autentifikācijas vai piekrišanas fāžu laikā, tiek apstrādātas tāpat kā autorizācijas koda plūsma un “Autorizācijas serverim OBLIGĀTI jāatdod kļūdas autorizācijas atbilde novirzīšanas URI fragmenta komponentā, kā noteikts OAuth 2.0 4.2.2.1. [RFC6749] un OAuth 2.0 daudzkārtējas atbildes veida kodēšanas prakses [OAuth.Responses], ja vien nav norādīts cits atbildes režīms. ”
  • RP apstiprina autentifikācijas atbildi, kā aprakstīts OIDC specifikācijas 3.3.2.8. Sadaļā.

Token parametram mijiedarbība atkal notiks tādā pašā veidā kā autorizācijas koda piešķīruma plūsma (saskaņā ar OIDC specifikācijas 3.3.3. Sadaļu), ar šādiem izņēmumiem:

  • No marķiera beigu punkta atgrieztā ID marķiera saturs ir tāds pats kā ID pilnvaras saturs, ko atgriezis autorizācijas galapunkts.
  • Ja ID marķieris tiek atgriezts no abiem parametriem, 3.3.3.6. Sadaļa pievieno papildu prasības, kurām jābūt izpildītām.
  • No marķiera galapunkta atgrieztais marķieris ir jāvalidē tādā pašā veidā kā autorizācijas koda plūsmai.
  • Ja piekļuves pilnvara tiek atgriezta no abiem parametriem, marķieri var būt vienādi vai atšķirīgi. Tas varētu būt noderīgi situācijā, kad drošības atribūti nosaka, kādi UI elementi tiek parādīti.

Šeit mēs neiedziļināsimies sīkāk par šo plūsmu, bet, ja jums nepieciešama papildu informācija, lielāko daļu informācijas var secināt no Autorizācijas koda piešķīruma plūsmas un Netiešās plūsmas diskusijām iepriekš.

Sākot pieteikšanos no trešās puses (IdP iniciēta pieteikšanās)

Ja jūs atcerēsities no iepriekšējiem SAML2 lietošanas gadījumiem, mēs apspriedām pakalpojumu sniedzēja (SP) - sākotnējo pieteikšanos un identitātes nodrošinātāja (IdP) - sākotnējo pieteikšanos. Visas līdz šim apspriestās autentifikācijas plūsmas pārstāv SP iniciētos pieteikšanās. OIDC specifikācijas 4. iedaļa definē, kā OpenID nodrošinātājs vai cita trešā puse var iniciēt pieteikšanos.

Lai OP sāktu pieteikšanās procesu, pieprasījums jānosūta uz pieteikšanās iniciācijas gala punktu RP ar šādiem parametriem:

iss: Nepieciešams. Tas ir OP izdevēja identifikators, kuram RP jānosūta autentifikācijas pieprasījums.

login_hint: pēc izvēles. Šis ir mājiens par vārdu (formātu / veidu), kuru ievadīs galalietotājs. Tas ļaus pieteikšanās darbplūsmai iepriekš aizpildīt lietotājvārdu.

target_link_uri: pēc izvēles. Šis ir URL, kas RP tiek pieprasīts, lai novirzītu lietotāju uz veiksmīgu autentifikāciju.

Papildu informāciju var atrast OIDC specifikācijā.

Rakstīšanas laikā OIDC IdP iniciētā (OP iniciētā, trešās puses iniciētā) pieteikšanās vēl nav tik izplatīta savvaļā. Bet, tā kā OIDC tiek pieņemts plašāk, būs nepieciešams atbalsts progresīvākiem lietošanas gadījumiem.

Līdzīgi, šo funkcionalitāti RP var izmantot arī vairāku operētājsistēmu (identitātes nodrošinātāju) atbalstam.

Atteikšanās atbalsts

OIDC sesiju pārvaldības specifikācija definē sesiju pārvaldību un atteikšanās funkcionalitāti. Šī specifikācija nav obligāta; tāpēc apstipriniet, ka OP un RP to atbalsta. Šajā ziņojumā netiks iekļauta papildu informācija par OIDC atteikšanos, taču šī tēma ir apskatīta šeit.

Kopsavilkums

Tas noslēdz mūsu diskusiju par OIDC.

Nākamajā šīs sērijas ievadā mēs beidzot apskatīsim JWT lietošanas gadījumus, izmantojot šajā sērijā uzzināto par JWT, OAuth2 un OIDC.

Atstājiet komentārus un jautājumus zemāk.