IdP-geïnitieerd SSO vs SP-geïnitieerd SSO
Leer meer over de verschillen tussen IdP-geïnitieerd SSO en SP-geïnitieerd SSO en waarom SP-geïnitieerd SSO veiliger is.
Leer meer over de verschillen tussen IdP-geïnitieerd SSO en SP-geïnitieerd SSO en waarom SP-geïnitieerd SSO veiliger is.
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.
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.

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.
IdP-geïnitieerd SSO draagt meer risico in vergelijking met SP-geïnitieerd SSO.
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.
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.
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.
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.
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).
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.