SAML2 vs JWT: võrdlus

Lukk ja võti / Kyle Pearson

See postitus lõpetab meie arutelu SAML2 ja JWT üle. Siin vaatleme kahe tehnoloogia omaduste ja kasutusjuhtude võrdlust. JWT ja SAML2 otsest võrdlust on keeruline. Nagu oleme selle sarja jooksul näinud, tuleb arvestada spetsifikatsioonidega, mis töötavad koos nende spetsifikatsioonidega.

JWT puhul peame arvestama:

  • OAuth2 spetsifikatsioonide perekond
  • OpenID Connecti spetsifikatsioonide perekond
  • JWE
  • JWS

SAML2 puhul peame arvestama

  • Spetsifikatsioonide perekond SAML2
  • XML-digitaalallkiri
  • XML-krüptimine
  • WS-turvalisus
  • WS-usaldus

Järgnevalt võetakse kokku peamised erinevused SAML2 ja JWT vahel. Selle postituse algses versioonis kasutati tabelivormingut, kuid Medium.com ei toeta tabeleid.

Vanus

SAML2: SAML 1.0 võeti kasutusele 2002. aastal; SAML2 võeti kasutusele 2005. aastal.

JWT: JWT RFC avaldati 2014. aastal. JWT on palju uuem.

Vastuvõtmine

SAML2: SAML2 on ettevõtte SSO defacto-standard. Nüüd on juba mõnda aega olnud.

JWT: JWT, OAuth2 ja OpenID Connect on sotsiaalmeedias ja tehnilistes idufirmades tavalised, kuid alles nüüd leiavad nad oma tee ettevõttesse.

Filosoofia

SAML2: Akadeemilisem lähenemine. Lihtsus polnud disaini eesmärk. Eeldati, et selle funktsionaalsuse rakendamiseks töötatakse välja käitusraamatukogud.

JWT: lihtne. Alustati eeldusest, et rakenduse arendaja rakendab kliendipoolset koodi. Kui spetsifikaadid küpsesid ja ettevõtted kasutusele võeti, hakkas kogukond sellest eemalduma.

Märgiliigid

SAML2: SAML kinnitus (vorming on rangelt määratletud spetsifikatsioonidega)

OAuth2: access_token (võib olla JWT, kuid ei pea seda olema)

OIDC: access_token (võib olla JWT) ja id-token (peab olema JWT).

Andmete struktuur

SAML2: XML (XSD-ga määratletud struktuur)

JWT: JSON (huvitaval kombel pole JSON-skeem seda struktuuri määratlenud)

Suurus

SAML2: kipub olema JWT-ga võrreldes väga suur. Suurus varieerub sõltuvalt olemasolevatest väljadest, allkirjade kasutamisest ja krüptimisest.

JWT: palju väiksem kui SAML2 märgid. Spetsifikaat julgustab viitamise asemel allkirjastamise sertifikaadile seda manustama - välistab suure x509 allkirjastaja sertifikaadi.

Sõnumiprotokollide toetamine

SAML2: suuresti SOAP-põhine.

JWT: REST API-d

Köited ja veoprotokollid

SAML2: SAML2 võib olla HTTP POST, HTTP GET, SOAP (sõltub stsenaariumist), JMS (harv, kuid võib juhtuda) jne.

JWT: HTTPS

Digitaalallkirjad

SAML2: XML-allkiri

JWT: JWS (toetatud räsimise ja krüptimise algoritmid erinevad pisut)

Sõnumitaseme krüptimine

SAML2: XML-krüptimine

JWT: JWE (toetatud krüptimisalgoritmid erinevad pisut) ***

X509 sertifikaadi esitus

SAML2: X509BinarySecurityToken tüüp

JWT: JSON veebivõtme spetsifikatsioon (JWK)

Põhispektri ulatus

SAML2: määratleb loa (SAML Assertion) ja selle aluseks oleva protokolli (Web App SSO jaoks) struktuuri.

JWT: JWT määratleb ainult sümboolse struktuuri. OAuth2 ja OpenID Connect määratlevad protokolli.

Kliendipoolne infrastruktuur

SAML2: nõuab üldjuhul toetavaid raamatukogusid (raskekaalulised)

JWT: Sageli saab seda rakendada lihtsa HTTP-päringu abil. Allkirjad ja krüptimine oleksid selle reegli erandid. *

Subjekti kinnitusmeetodi tugi

SAML2: SAML2 toetab kanderakette, võtmehoidjat ja saatjavautšere.

JWT: JWT toetas algselt ainult kandjamärke. Võtme omanik (tõend valduse toe kohta lisatud aprillis 2016).

Delegeerimine ja kellegi teisena esinemine (OnBehalfOf and ActAs)

SAML2: määratletud WS-Trusti spetsifikatsioonis

JWT: OAuth2 laiendi spetsifikatsioon (OAuth2 Token Exchange Spec)

Dünaamiliste usaldusaluste värskenduste ja metaandmete teabe avaldamise tugi.

SAML2: WS-Federation spetsifikatsioon määratleb, kuidas seda teavet avaldada. Kuid seda ei kasutata üldiselt. On haruldane, et kliendid hangivad dünaamiliselt IdP-i avaldatud teavet, et värskendada oma allkirjastaja sertifikaadi usaldussüsteemi.

JWT: OpenID Connect Discovery spetsifikatsioon määratleb metaandmete lõpp-punkti, mis avaldab IdP metaandmeid. On tungivalt soovitatav konstrueerida kliente, kellel on sellele teabele juurde pääseda ja usaldushinda dünaamiliselt üles ehitada / värskendada. **

* Teekide kasutamine on peaaegu alati soovitatav, kui päringuid / taotlusi luuakse nullist.

** See üks detail võib potentsiaalselt kokku hoida 1000 tundi inimtundi, kui allkirjastaja sertifikaati tuleb uuendada.

*** JWE ja XML-krüptimisel on ka mitmeid olulisi erinevusi, kuid sellesse sarja pole ma veel jõudnud :).

Kõik erinevused, mis on toodud XML DSig vs. JSON Web Signature Series-is, kehtivad ka siin.

Pilt: lukk ja võti / Kyle Pearson