IdP-initiiertes SSO vs. SP-initiiertes SSO
Erfahren Sie mehr über die Unterschiede zwischen IdP-initiiertem SSO und SP-initiiertem SSO und warum SP-initiiertes SSO sicherer ist.
Erfahren Sie mehr über die Unterschiede zwischen IdP-initiiertem SSO und SP-initiiertem SSO und warum SP-initiiertes SSO sicherer ist.
Wie der Name schon sagt, wird das SP-initiierte SSO vom Service Provider initiiert. Der Benutzer startet den Authentifizierungsprozess, indem er auf eine Ressource auf der Website des SP zugreift. Der SP leitet den Benutzer dann zur Authentifizierung an den IdP weiter. Sobald der Benutzer authentifiziert ist, generiert der IdP ein Token (OIDC) oder eine SAML-Assertion (SAML) und sendet es zurück an den SP. Der SP validiert das Token oder die Assertion und gewährt dem Benutzer Zugang.
Im Gegensatz zum SP-initiierten SSO wird das IdP-initiierte SSO vom Identity Provider initiiert. Der Benutzer startet den Authentifizierungsprozess von der Website des IdP aus. Normalerweise findet der Benutzer eine Liste unterstützter SP-Anwendungen auf dem Portal des IdP. Der Benutzer klickt auf die SP-Anwendung und wird mit einer vor-autentifizierten Identität zur Website des SP weitergeleitet.

IdP-initiierter SSO wird häufiger von großen Unternehmen und Organisationen verwendet, die auf verschiedene Drittanbieter-Apps oder -Dienste angewiesen sind, wie Workday, Salesforce usw. Es bietet eine zentrale Möglichkeit zur Verwaltung des Benutzerzugangs zu mehreren Anwendungen und zur Durchsetzung von SSO-Authentifizierungen. Durch die Aktivierung von IdP-initiiertem SSO können Mitarbeiter direkt über das Portal des IdP auf die verbundenen Anwendungen zugreifen, ohne die Website jeder Anwendung besuchen zu müssen, wodurch die Einarbeitungszeit verkürzt und das Benutzererlebnis verbessert wird.
IdP-initiierter SSO birgt gegenüber SP-initiiertem SSO mehr Risiken.
Fehlender Authentifizierungskontext: Alle vom IdP initiierten Authentifizierungsanforderungen sind unaufgefordert. Somit initiiert der SP den Authentifizierungsprozess, was möglicherweise die Tür für unbefugten Zugriff öffnet. Es besteht das Risiko, dass die Sitzung des Benutzers gekapert werden könnte. Ein bösartiger Akteur könnte den Anmeldeprozess für einen legitimen Benutzer ohne dessen Wissen oder Zustimmung einleiten.
Sitzungsfixierung: Da der SP den Authentifizierungsprozess nicht initiiert, könnte die Sitzung des Benutzers auf die Sitzung des IdP festgelegt werden. Dies könnte zu Sitzungsfixierungsangriffen führen, bei denen ein Angreifer die Sitzung des Benutzers mit der Sitzung des IdP verknüpfen und unbefugten Zugang zum Konto des Benutzers erlangen könnte.
Phishing-Angriffe: IdP-initiierter SSO könnte anfällig für Phishing-Angriffe sein. Ein bösartiger Akteur könnte den Benutzer dazu verleiten, ein gefälschtes IdP-Portal zu besuchen und seine Anmeldedaten zu stehlen. Sobald sich der Benutzer anmeldet, könnte der Angreifer den Benutzer mit einer vor-autentifizierten Identität an den SP weiterleiten.
Keine Sicherstellung der Anforderungsvalidierung: In einem SP-initiierten SSO wird normalerweise das SP die erforderlichen Sicherheitsinformationen in die Anforderung an den IdP aufnehmen, um die Integrität der Anforderung zu gewährleisten. Sobald das SP die Authentifizierungsantwort erhält, wird es diese Informationen validieren, um CSRF-Angriffe zu verhindern. Z.B. der state-Parameter in OIDC und RelayState in SAML. In IdP-initiiertem SSO initiiert der SP jedoch den Authentifizierungsprozess nicht, sodass das SP keine Sicherstellung der Anforderungsvalidierung hat.
IdP-initiiertes SSO wird von OIDC aufgrund der oben genannten Schwachstellen nicht unterstützt. OIDC erfordert, dass der SP den Authentifizierungsprozess initiiert, um die Integrität der Anforderung sicherzustellen. Selbst in Fällen, in denen Benutzer den Authentifizierungsprozess von einem Drittanbieter starten, der nicht der SP ist, sollte der Benutzer zuerst an den SP weitergeleitet werden, um den Authentifizierungsprozess zu initiieren.
Aber in SAML ist IdP-initiiertes SSO möglich. Der IdP kann eine SAML-Assertion generieren, ohne dass der SP den Authentifizierungsprozess initiiert. In einem SAML IdP-initiierten SSO könnte eine SAML-Assertion ohne ordnungsgemäßes RequestID und RelayState direkt an die ACS-URL des SP gesendet werden. Der SP sollte in der Lage sein, diese Art von Assertion zu verarbeiten und dem Benutzer Zugang zu gewähren. (Hinweis: Ohne RequestID und RelayState hat der SP keine Sicherstellung der Integrität der Anforderung).
Obwohl IdP-initiiertes SSO eine zentrale Möglichkeit bietet, den Benutzerzugang zu mehreren Anwendungen zu verwalten, birgt es im Vergleich zu SP-initiiertem SSO mehr Risiken. SP-initiiertes SSO ist sicherer und bietet mehr Sicherheiten hinsichtlich der Integrität der Authentifizierungsanforderung. Es wird empfohlen, SP-initiiertes SSO sowohl für OIDC als auch für SAML-basiertes SSO zu verwenden.