IdP-geïnitieerd SSO vs SP-geïnitieerd SSO#

Terminologie#

• Identity Provider (IdP): De dienst die gebruikersidentiteiten opslaat en verifieert.
• Service Provider (SP): Een web- of service die diensten aan gebruikers levert.
• Single Sign-On (SSO): Een sessie- en gebruikersauthenticatiedienst die een gebruiker toestaat om één set inloggegevens (bijv. naam en wachtwoord) te gebruiken om toegang te krijgen tot meerdere applicaties.
• SAML: Security Assertion Markup Language is een open standaard voor het uitwisselen van authenticatie- en autorisatiegegevens tussen partijen, met name tussen een identiteit provider en een service provider. Het is een veelgebruikt protocol voor SSO. Zodra een gebruiker met succes door de IdP is geauthenticeerd, stuurt de IdP een SAML-assertie naar de SP, die de SP valideert en toegang verleent aan de gebruiker.
• OIDC: OpenID Connect is een modernere en veiligere protocol voor SSO. Het is gebaseerd op OAuth 2.0 en biedt een manier om de identiteit van de gebruiker te verifiëren op basis van de authenticatie uitgevoerd door de IdP. Zodra een gebruiker succesvol is geauthenticeerd door de IdP, stuurt de IdP een JWT-geformatteerd token naar de SP, die de SP valideert en toegang verleent aan de gebruiker.

SP-geïnitieerd SSO#

Zoals de naam suggereert, wordt SP-geïnitieerd SSO geïnitieerd door de service provider. De gebruiker start het authenticatieproces door toegang te verkrijgen tot een bron op de website van de SP. De SP leidt de gebruiker vervolgens door naar de IdP voor authenticatie. Zodra de gebruiker is geauthenticeerd, genereert de IdP een token (OIDC) of een SAML-assertie (SAML) en stuurt deze terug naar de SP. De SP valideert de token of de assertie en verleent toegang aan de gebruiker.

1. Gebruiker bezoekt de website van de SP en probeert toegang te krijgen tot een bron.
2. Gebruiker klikt op de inlogknop van de SSO-provider (bijv. Google, Azure AD, Okta, enz.).
3. SP leidt de gebruiker door naar de IdP voor authenticatie.
4. Gebruiker logt in bij de IdP.
5. IdP stuurt een token of assertie terug naar de SP.
6. SP valideert de token of assertie en verleent toegang aan de gebruiker.

IdP-geïnitieerd SSO#

In tegenstelling tot SP-geïnitieerd SSO, wordt IdP-geïnitieerd SSO geïnitieerd door de identiteit provider. De gebruiker start het authenticatieproces vanaf de website van de IdP. Normaal gesproken vindt de gebruiker een lijst met ondersteunde SP-applicaties op het IdP-portaal. De gebruiker klikt op de SP-applicatie en wordt doorgestuurd naar de website van de SP met een vooraf geauthenticeerde identiteit.

1. Gebruiker logt in bij de IdP.
2. Gebruiker bezoekt het IdP-portaal en selecteert een SP-applicatie.
3. IdP valideert de huidige sessie van de gebruiker en leidt de gebruiker door naar de SP met een vooraf geauthenticeerde SSO-identiteit.
4. SP valideert de SSO-identiteit en verleent toegang aan de gebruiker.

IdP-geïnitieerd SSO vs SP-geïnitieerd SSO#

Voordelen van IdP-geïnitieerd SSO vergeleken met SP-geïnitieerd SSO#

IdP-geïnitieerd SSO wordt meer toegepast door grote bedrijven en organisaties die afhankelijk zijn van verschillende apps of diensten van derden. Zoals Workday, Salesforce enz. Het biedt een gecentraliseerde manier om gebruikers toegang te beheren tot meerdere applicaties en om SSO-authenticaties af te dwingen. Door IdP-geïnitieerd SSO in te schakelen, kunnen werknemers rechtstreeks toegang krijgen tot de verbonden applicaties vanuit het portaal van de IdP zonder dat ze elke applicatiewebsite hoeven te bezoeken. Hierdoor wordt de onboarding-tijd verkort en de gebruikerservaring verbeterd.

Risico's van IdP-geïnitieerd SSO vergeleken met SP-geïnitieerd SSO#

IdP-geïnitieerd SSO draagt meer risico in vergelijking met SP-geïnitieerd SSO.

1. Gebrek aan authenticatiecontext: Alle authenticatieverzoeken geïnitieerd door IdP zijn ongevraagd. Dus de SP startte het authenticatieproces, wat mogelijk de deur opent voor ongeautoriseerde toegang. Er is een risico dat de sessie van de gebruiker kan worden gehackt. Een kwaadwillende actor zou het inlogproces kunnen starten voor een legitieme gebruiker zonder hun kennis of toestemming.

2. Sessiefixatie: Aangezien de SP het authenticatieproces niet initieert, kan de sessie van de gebruiker worden gefixeerd aan de sessie van de IdP. Dit kan leiden tot sessiefixatie-aanvallen waarbij een aanvaller de sessie van de gebruiker kan fixeren aan de sessie van de IdP en ongeautoriseerde toegang kan krijgen tot het account van de gebruiker.

3. Phishing-aanvallen: IdP-geïnitieerd SSO zou kwetsbaar kunnen zijn voor phishing-aanvallen. Een kwaadwillende actor zou de gebruiker kunnen misleiden om naar een nepportaal van de IdP te gaan en de inloggegevens van de gebruiker te stelen. Zodra de gebruiker inlogt, kan de aanvaller de gebruiker omleiden naar de SP met een vooraf geauthenticeerde identiteit.

4. Geen garantie op verzoekvalidatie: In een SP-geïnitieerd SSO omvat normaal gesproken de SP noodzakelijke beveiligingsinformatie in het verzoek aan de IdP om de integriteit van het verzoek te behouden. Zodra de SP de authenticatie-respons ontvangt, zal het deze informatie valideren om eventuele CSRF-aanvallen te voorkomen. Bijv. De state-parameter in OIDC en RelayState in SAML. In IdP-geïnitieerd SSO initieert de SP echter het authenticatieproces niet, dus de SP heeft geen garantie op de verzoekvalidatie.

Beperkingen van IdP-geïnitieerd SSO vergeleken met SP-geïnitieerd SSO#

IdP-geïnitieerd SSO wordt niet ondersteund door OIDC vanwege de bovengenoemde kwetsbaarheden. OIDC vereist dat de SP het authenticatieproces initieert om de integriteit van het verzoek te waarborgen. Zelfs in gevallen waarin gebruikers het authenticatieproces starten vanaf een derde partij die niet de SP is, moet de gebruiker eerst naar de SP worden geleid om het authenticatieproces te starten.

Maar in SAML is IdP-geïnitieerd SSO mogelijk. De IdP kan een SAML-assertie genereren zonder dat de SP het authenticatieproces initieert. In een SAML IdP-geïnitieerd SSO kan een SAML-assertie zonder een correcte RequestID en RelayState direct naar de ACS URL van de SP worden gestuurd. De SP moet in staat zijn om dit soort asserties te verwerken en de gebruiker toegang te verlenen. (Opmerking: Zonder de RequestID en RelayState heeft de SP geen garantie van de integriteit van het verzoek).

Conclusie#

Hoewel IdP-geïnitieerd SSO een gecentraliseerde manier biedt om gebruikers toegang te beheren tot meerdere applicaties, draagt het meer risico's in vergelijking met SP-geïnitieerd SSO. SP-geïnitieerd SSO is veiliger en biedt meer zekerheid over de integriteit van het authenticatieverzoek. Het is aanbevolen om SP-geïnitieerd SSO te gebruiken voor zowel OIDC- als SAML-gebaseerde SSO.