OIDC of SAML: watter een jy werklik nodig het

Elke span wat B2B-sagteware bou, kom by dieselfde tweesprong die eerste keer wat 'n ernstige klant sê "ons benodig SSO." Twee akronieme, OIDC en SAML, wat albei aanspraak maak dat hulle die antwoord is, en 'n internet vol vergelykingstabelle wat vir jou sê SAML is "enterprise" en OIDC is "modern" en jou presies net so vasgevang laat as voorheen. Hier is die weergawe wat jou werklik help om te lewer.

Wat hulle is

SAML is van 2005 en dit is XML. 'n Identiteitsverskaffer onderteken 'n bewering ("dit is [email protected], hier is haar groepe") en stuur dit na jou toepassing, wat die handtekening nagaan en haar aanmeld. Dit is gebou vir die blaaier en vir werksmag-identiteit, in 'n era toe "die enterprise" 'n ter-plaatse Active Directory en 'n SOAP-stapel beteken het. Dit is breedsprakig, dit is oud, en dit is absoluut oral binne groot organisasies, wat die een feit daaroor is wat vir jou saak maak.

OIDC is van 2014 en dit is JSON en JWT's, wat bo-op OAuth 2.0 sit. 'n Identiteitsverskaffer reik 'n ID-token uit wat jou toepassing valideer. Dit is gebou vir die moderne web: SPA's, mobiele toepassings, API's, sosiale aanmelding. Dit is skoner, beter gespesifiseer vir die dinge wat jy vandag werklik bou, en die protokol wat die meeste splinternuwe identiteitsprojekte deesdae praat.

Wanneer elkeen wen

Die eerlike antwoord op "watter een moet ek bou" is dat jy byna nooit die keuse kry nie. Jy bou die een wat jou klant se IT-afdeling gekies het, en hulle het dit gekies lank voordat hulle van jou gehoor het.

• 'n Klant op Okta, Entra ID of Google Workspace kan gewoonlik enige van die twee doen, en OIDC is die mooier pad.
• 'n Klant op 'n ouer ADFS, 'n verouderde ter-plaatse IdP, of 'n aankoopkontrolelys wat in 2016 geskryf is, sal vir jou 'n stuk SAML-metadata en 'n kalenderuitnodiging gee, en dis die einde van die gesprek.
• Jou eie eerstepartytoepassings, jou dashboard en jou mobiele kliënt, wil OIDC hê, punt. Jy sou nooit na SAML gryp om 'n gebruiker by jou eie React-toepassing aan te meld nie.

So die veld verdeel skoon: OIDC vir die moderne en die eerste party, SAML vir "want die enterprise het so gesê." Verkoop aan genoeg enterprises en jy sal vir albei gevra word. Nie uiteindelik nie. Herhaaldelik.

Die slaggate, waar dit duur word om dit self te bou

SAML se probleem is dat dit 'n ondertekende-XML-protokol is, en ondertekende XML is een van die mees betroubaar gevaarlike dinge in toegepaste kriptografie. Die maniere om SAML-handtekeningverifikasie verkeerd te kry, is talryk en berug:

• Handtekeningomvouing (XSW): 'n aanvaller skuif die ondertekende element en glip 'n ongetekende, vervalste bewering in waar jou ontleder werklik lees. As jy die handtekening nagaan en die bewering as twee afsonderlike stappe lees, is jy waarskynlik kwesbaar, en byna elke eerste implementasie doen presies dit.
• Kanonisering en kommentaarinspuiting: die 2018-klas foute waar [email protected]<!---->.evil.com op een manier kanoniseer vir die handtekeningkontrole en op 'n ander manier vir die string wat jou kode lees, sodat jy vrolik die verkeerde persoon staaf. Werklike CVE's, verskeie groot biblioteke.
• Die stiller gevalle: die respons onderteken maar nie die bewering nie, ongetekende beweringe aanvaar, die IdP-verskafte uitreiker vertrou sonder om dit vas te pen, die bewering se geldigheidsvenster verkeerd kry. Elkeen is sy eie slaggat, en elkeen is na produksie gestuur deur mense wat geweet het wat hulle doen.

OIDC is betekenisvol verstandiger, maar dit is nie vry van skerp kante nie. Jy moet steeds die regte eise valideer (iss, aud, exp, die nonce), PKCE gebruik, die lankal-dooie implisiete vloei weier, en JWKS roteer en kas sonder om 'n token te verwerp wat onderteken is met 'n sleutel wat jy nog nie afgehaal het nie. Die verskil is dat OIDC se slaggate gedokumenteer is, JSON-vormig is, en standaard korrek hanteer word in die meeste biblioteke. SAML se slaggate is XML-vormig en het sekuriteitspanne verorber wat baie beter toegerus is as joune.

Die werklike antwoord

"OIDC of SAML" is die verkeerde vraag, want die regte antwoord vir 'n B2B-produk is "ja." Jou moderne klante en jou eie toepassings wil OIDC hê. Jou enterprise-klante sal SAML afdwing op 'n tydlyn wat jy nie beheer nie. Bou vir een, en die derde verkoopsoproep breek dit.

Wat jy werklik nodig het, is 'n manier om watter protokol ook al elke klant bring te aanvaar, sonder om twee stapels op te stel, twee stelle metadata-pypwerk, en twee onafhanklike kanse om handtekeningverifikasie verkeerd te kry. Die implementasie is die koste. Die keuse was nog nooit die moeilike deel nie.

Dit is die deel wat Authagonal van jou bord af haal. Elke huurder kry SAML 2.0 met een-klik-metadata-invoer en OIDC-federasie met die verskaffers wat jou klante reeds gebruik, op dieselfde aanmelding, sonder 'n per-verbinding-fooi vir enige van die twee. Jy implementeer nie XML-handtekeningverifikasie nie, jy pas nie 'n JWKS-kas op nie, en jy herbou niks daarvan wanneer die volgende klant opdaag wat die ander protokol praat nie. Sien wat ingesluit is.