SAML och OpenID Connect

Vad protokollen gör

Båda protokollen löser samma grundproblem. Applikationen ska inte behöva veta hur en användare autentiseras, bara kunna lita på resultatet.

Flödet är i grunden detsamma i båda fallen:

1. Användaren försöker nå en applikation.
2. Applikationen skickar användaren vidare till Identity Provider.
3. Identity Provider autentiserar användaren med den metod som gäller för flödet.
4. Användaren skickas tillbaka med ett intyg om vem hen är och hur autentiseringen skedde.
5. Applikationen kontrollerar intyget och släpper in användaren.

Det som skiljer protokollen är hur intyget i steg fyra ser ut, hur det skyddas och hur det överförs.

Assertion, token och claims

SAML levererar en assertion: ett XML-dokument som beskriver vem användaren är, vem som har utfärdat intyget, hur länge det är giltigt och vilka attribut som följer med. Assertionen signeras av Identity Provider, och applikationen verifierar signaturen mot en känd nyckel.

OpenID Connect levererar i stället en ID-token, ett signerat JWT i JSON-format, tillsammans med claims – enskilda uppgifter om användaren. OpenID Connect är byggt som ett identitetslager ovanpå OAuth 2.0, vilket innebär att samma modell också kan ge applikationen access-token för att anropa API:er i användarens namn.

Skillnaden i format har praktiska konsekvenser. XML-signaturhantering är mer krävande att implementera korrekt, medan JWT och JSON hanteras direkt av moderna webb- och mobilramverk. Å andra sidan har SAML en lång historia i verksamhetssystem och en etablerad tolkning av attribut och metadata som många upphandlade system redan följer.

När passar SAML och när passar OpenID Connect

SAML är vanligt i etablerade enterprise- och myndighetsnära miljöer. OpenID Connect är ofta mer naturligt i moderna webb-, mobil- och API-nära lösningar. Principen är densamma i båda fallen: applikationen får en kontrollerad identitetsleverans.

I praktiken avgörs valet oftast av applikationen, inte av arkitekturen:

• Ett upphandlat verksamhetssystem har ofta redan en SAML-integration, och då är SAML den snabbaste vägen till anslutning.
• En egenutvecklad tjänst, en mobilapp eller en lösning som ska anropa API:er passar bättre med OpenID Connect.
• En organisation med båda typerna behöver kunna erbjuda båda, samtidigt, utan att dela upp inloggningsupplevelsen.

Det sista fallet är det vanliga. Därför är frågan sällan vilket protokoll organisationen ska välja, utan hur båda kan användas mot samma identitetsmodell.

Federativ brokering och tokenöversättning

Identity Provider kan fungera som en federativ broker mellan identitetsleverantörer och applikationer. Det gör det möjligt att översätta identitetsinformation och tokens mellan SAML och OpenID Connect, i båda riktningarna, så att äldre och moderna tjänster kan samverka inom samma autentiseringsflöde.

Konkret innebär det att protokollet mot användarens identitetskälla inte behöver vara detsamma som protokollet mot applikationen. En applikation som bara talar SAML kan nås via ett flöde som i sin tur bygger på OpenID Connect, och omvänt. Organisationen slipper därmed att välja mellan att modernisera protokollet och att behålla de system som redan fungerar.

Brokeringen är också det som gör en stegvis migrering möjlig. Applikationerna kan flyttas en åt gången, i den takt verksamheten klarar, utan att inloggningsmodellen behöver bytas ut i ett enda steg. Det är samma mekanism som gör att IDOmbud kan användas parallellt med en befintlig identitetsmiljö – se Entra ID och IDOmbud.

Vad applikationen behöver hantera

Oavsett protokoll behöver den anslutande applikationen ta ställning till några saker:

• vilken identifierare som pekar ut användaren, och att den är stabil över tid
• vilka attribut eller claims applikationen faktiskt behöver, och inte fler än det
• hur intygets giltighetstid och signatur kontrolleras
• hur utloggning ska fungera, och om SSO-sessionen ska brytas i fler tjänster än en
• hur applikationen ska agera när autentiseringen inte uppfyller kravnivån

Den sista punkten är den som oftast missas. En applikation som bara kontrollerar att användaren är inloggad, men inte hur, kan inte skilja en svag inloggning från en stark. Se step-up och MFA för hur kravnivån hanteras i flödet.

Tillitsnivå och spårbarhet

Protokollet bär inte bara identiteten, utan också informationen om hur den fastställdes. Både SAML och OpenID Connect har utrymme för att beskriva vilken autentiseringsmetod som användes och vilken nivå den motsvarar.

För LoA3 och LoA4 räcker det inte att användaren kan logga in med en stark metod. Organisationen behöver också kunna visa hur identiteten kontrollerades, hur autentiseringen skyddades, hur rätt tillitsnivå förmedlades och hur händelsen kan följas upp. Protokollvalet är alltså en del av ansvarskedjan, inte bara en teknisk integrationsdetalj. Läs mer om LoA4 och tillitsnivåer.