IdP-initierad SSO vs SP-initierad SSO#

Terminologi#

• Identity Provider (IdP): Tjänsten som lagrar och autentiserar användaridentiteter.
• Service Provider (SP): En webb eller tjänst som tillhandahåller tjänster till användare.
• Single Sign-On (SSO): En session och användarautentiseringstjänst som tillåter en användare att använda en uppsättning inloggningsuppgifter (t.ex. namn och lösenord) för att få åtkomst till flera applikationer.
• SAML: Security Assertion Markup Language är en öppen standard för att utbyta autentiserings- och auktoriseringsdata mellan parter, särskilt mellan en identitetsleverantör och en tjänsteleverantör. Det är ett vanligt använt protokoll för SSO. När en användare har autentiserats framgångsrikt av IdP, skickar IdP en SAML-assertion till SP, som SP validerar och ger användaren åtkomst.
• OIDC: OpenID Connect är ett mer modernt och säkert protokoll för SSO. Det bygger på OAuth 2.0 och erbjuder ett sätt att verifiera användarens identitet baserat på autentiseringen som utförs av IdP. När en användare har autentiserats framgångsrikt av IdP, skickar IdP en JWT-formaterad token till SP, som SP validerar och ger användaren åtkomst.

SP-initierad SSO#

Som namnet antyder initieras SP-initierad SSO av tjänsteleverantören. Användaren startar autentiseringsprocessen genom att få åtkomst till en resurs på SP:s webbplats. SP omdirigerar sedan användaren till IdP för autentisering. När användaren har autentiserats genererar IdP en token (OIDC) eller en SAML-assertion (SAML) och skickar den tillbaka till SP. SP validerar tokenen eller assertionen och ger användaren åtkomst.

1. Användaren besöker SP:s webbplats och försöker få åtkomst till en resurs.
2. Användaren klickar på SSO-leverantörens inloggningsknapp (t.ex. Google, Azure AD, Okta, etc).
3. SP omdirigerar användaren till IdP för autentisering.
4. Användaren loggar in på IdP.
5. IdP skickar en token eller assertion tillbaka till SP.
6. SP validerar tokenen eller assertionen och ger användaren åtkomst.

IdP-initierad SSO#

Till skillnad från SP-initierad SSO initieras IdP-initierad SSO av identitetsleverantören. Användaren startar autentiseringsprocessen från IdP:s webbplats. Normalt hittar användaren en lista över stödda SP-applikationer på IdP:s portal. Användaren klickar på SP-applikationen och omdirigeras till SP:s webbplats med en för-autentiserad identitet.

1. Användaren loggar in på IdP.
2. Användaren besöker IdP:s portal och väljer en SP-applikation.
3. IdP validerar användarens nuvarande session och omdirigerar användaren till SP med en för-autentiserad SSO-identitet.
4. SP validerar SSO-identiteten och ger användaren åtkomst.

Idp-initierad SSO vs SP-initierad SSO#

Fördelar med IdP-initierad SSO jämfört med SP-initierad SSO#

IdP-initierad SSO används mer av stora företag och organisationer som förlitar sig på olika tredjepartsappar eller tjänster. Som Workday, Salesforce etc. Det ger ett centraliserat sätt att hantera användaråtkomst till flera applikationer och tillämpa SSO-autentiseringar. Genom att möjliggöra IdP-initierad SSO kan anställda direkt få åtkomst till de anslutna applikationerna från IdP:s portal utan att behöva besöka varje applikations webbplats. Detta minskar tid för introduktion och förbättrar användarupplevelsen.

Risker med IdP-initierad SSO jämfört med SP-initierad SSO#

IdP-initierad SSO medför större risker jämfört med SP-initierad SSO.

1. Brist på autentiseringskontext: Alla autentiseringsförfrågningar som initieras från IdP är oönskade. Således kan SP initiera autentiseringsprocessen, vilket potentiellt öppnar dörren för obehörig åtkomst. Det finns en risk att användarens session kan kapas. En illasinnad aktör kan initiera inloggningsprocessen för en legitim användare utan deras vetskap eller samtycke.

2. Sessionsfixering: Eftersom SP inte initierar autentiseringsprocessen kan användarens session fixeras till IdP:s session. Detta kan leda till sessionsfixeringsattacker där en angripare kan fixera användarens session till IdP:s session och få obehörig åtkomst till användarens konto.

3. Phishingattacker: IdP-initierad SSO kan vara sårbar för phishingattacker. En illasinnad aktör kan lura användaren att besöka en falsk IdP:s portal och stjäla användarens uppgifter. När användaren loggar in kan angriparen omdirigera användaren till SP med en för-autentiserad identitet.

4. Ingen försäkran om förfrågningsvalidering: I en SP-initierad SSO inkluderar oftast SP nödvändig säkerhetsinformation i förfrågan till IdP för att upprätthålla förfrågningens integritet. När SP mottar autentiseringssvaret kommer det att validera denna information för att förhindra CSRF-attacker. Exempelvis state-parametern i OIDC och RelayState i SAML. Men i IdP-initierad SSO initierar inte SP autentiseringsprocessen och har därför ingen försäkran om förfrågningsvalidering.

Begränsningar av IdP-initierad SSO jämfört med SP-initierad SSO#

IdP-initierad SSO stöds inte av OIDC på grund av ovanstående sårbarheter. OIDC kräver att SP initierar autentiseringsprocessen för att säkerställa förfrågningens integritet. Även i fall där användare börjar autentiseringsprocessen från en tredje part som inte är SP, bör användaren först styras till SP för att initiera autentiseringsprocessen.

Men i SAML är IdP-initierad SSO möjligt. IdP kan generera en SAML-assertion utan att SP initierar autentiseringsprocessen. I en SAML IdP-initierad SSO kan en SAML-assertion utan en ordentlig RequestID och RelayState skickas direkt till SP:s ACS URL. SP bör kunna hantera denna typ av assertion och ge användaren åtkomst. (Obs: Utan RequestID och RelayState har SP ingen försäkran om förfrågningens integritet).

Slutsats#

Även om IdP-initierad SSO ger ett centraliserat sätt att hantera användaråtkomst till flera applikationer, medför det större risker jämfört med SP-initierad SSO. SP-initierad SSO är mer säker och ger mer försäkran om autentiseringsförfrågningens integritet. Det rekommenderas att använda SP-initierad SSO för både OIDC- och SAML-baserad SSO.