Clarify IdP-initiated SSO section: specify login CSRF, remove MITM re… #1876#1882
Clarify IdP-initiated SSO section: specify login CSRF, remove MITM re… #1876#18820xgaurav wants to merge 1 commit intoOWASP:masterfrom
Conversation
0xgaurav
requested review from
jmanico,
kwwall,
mackowski and
szh
as code owners
|
@0xgaurav looks good but linter check if failing, please fix that. Also please next time use our PR template for Pull Request because it contains a checklist that would for example allow you to find and fix this much earlier. |
|
Also I see that this issue is assigned to @madaster97 |
There was a problem hiding this comment.
Pull Request Overview
This PR improves the documentation in the SAML Security Cheat Sheet by expanding and clarifying the security considerations for IdP-initiated SSO (Unsolicited Response). The changes provide more nuanced technical explanations of the security trade-offs involved.
- Clarified that IdP-initiated SSO specifically lacks "login CSRF" protection and explained why
- Added important context distinguishing MITM attack risks from login intent validation issues
- Improved explanation of backward compatibility rationale for continued IdP-initiated SSO support
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Thanks for letting me know! I didn’t realize this issue was already assigned — my apologies. |
|
I'm happy for @0xgaurav 's PR to go through! |
| ## Unsolicited Response (ie. IdP Initiated SSO) Considerations for Service Providers | ||
|
|
||
| Unsolicited Response is inherently [less secure](https://www.identityserver.com/articles/the-dangers-of-saml-idp-initiated-sso) by design due to the lack of [CSRF](https://owasp.org/www-community/attacks/csrf) protection. However, it is supported by many due to the backwards compatibility feature of SAML 1.1. The general security recommendation is to not support this type of authentication, but if it must be enabled, the following steps (in addition to everything mentioned above) should help you secure this flow: | ||
| Unsolicited Response is inherently less secure by design due to the lack of **login [CSRF](https://owasp.org/www-community/attacks/csrf)** protection. This limitation arises because the Service Provider (SP) has no opportunity to create a pre-login session or verify that the authentication request was intentionally initiated by the user. |
There was a problem hiding this comment.
Could we use this specific link / section?
https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#possible-csrf-vulnerabilities-in-login-forms
There was a problem hiding this comment.
Thanks for the suggestion! Yes, that link fits better and points directly to the relevant CSRF section. I’ll update the reference to use this specific section from the OWASP CSRF Prevention Cheat Sheet.
|
Thanks @madaster97 and thanks for PR review! |
| ## Unsolicited Response (ie. IdP Initiated SSO) Considerations for Service Providers | ||
|
|
||
| Unsolicited Response is inherently less secure by design due to the lack of **login [CSRF](https://owasp.org/www-community/attacks/csrf)** protection. This limitation arises because the Service Provider (SP) has no opportunity to create a pre-login session or verify that the authentication request was intentionally initiated by the user. | ||
| Unsolicited Response is inherently less secure by design due to the lack of **login [CSRF](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#possible-csrf-vulnerabilities-in-login-forms)** protection. This limitation arises because the Service Provider (SP) has no opportunity to create a pre-login session or verify that the authentication request was intentionally initiated by the user. |
There was a problem hiding this comment.
We generally link to the .md files and the website builder rewrites them when publishing. That way it works when browsing the repo as well as on the website.
| Unsolicited Response is inherently less secure by design due to the lack of **login [CSRF](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#possible-csrf-vulnerabilities-in-login-forms)** protection. This limitation arises because the Service Provider (SP) has no opportunity to create a pre-login session or verify that the authentication request was intentionally initiated by the user. | |
| Unsolicited Response is inherently less secure by design due to the lack of **login [CSRF](Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.md#possible-csrf-vulnerabilities-in-login-forms)** protection. This limitation arises because the Service Provider (SP) has no opportunity to create a pre-login session or verify that the authentication request was intentionally initiated by the user. |
There was a problem hiding this comment.
We should really make note of this explicitly in our docs, and add a linter for it...
There was a problem hiding this comment.
@jmanico @mackowski just waiting on this to be corrected
6 participants
Summary
This PR improves the "IdP Initiated SAML SSO" section of the SAML Security Cheat Sheet.
Rationale
This aligns the cheat sheet with accurate security reasoning while keeping the focus on real, design-based risks rather than general TLS issues.
Covers: #1876