SAML sucks, but it still has a bunch of features for its specific narrow enterprise SSO use-case that OIDC lacks - most notably IdP-initiated flow. OIDC is a constellation of specs with inconsistent support across products, whereas the commonly-implemented subset of SAML is more-or-less stable in its mediocrity.
OIDC will eventually displace SAML, but if you're selling to enterprises you should really support both. Both will pale compared to the amount of time you spend dealing with SCIM inconsistencies between IdPs anyway.
OIDC doesn't support IDP initiated flows for a reason - they're vulnerable to a class of attacks known as Login CSRF. An attacker can trick a victim into submitting an IdP-initiated authentication response linked to the attacker's account/session into the victim's browser profile on the SP. Think - Eve tricks Bob into signing in to Eve's PayPal account instead of Bob's. Bob, none the wiser, links his bank account. Eve now has access to Bob's funds.
IdPs that need to support an "IdP-initiated" user experience (like a portal or dashboard where users click an app icon) should instead have that icon link to a specific landing page on the SP that safely kicks off a standard, SP-initiated OIDC flow. IdP -> (SP -> IdP -> SP). Look at Okta's "Initiate Login URI" for an example of this.
SAML implementations can protect against this by turning IdP-initiated requests into an SP-initiated request. On the SP-initiated responses, there is an `InResponseTo` field that can be validated (or `RelayState` can be made to work).
The OIDC specification is pretty hand-wavy about how to prevent this attack as well. So don't assume all OIDC implementations do.
OIDC spec has a limited third-party initiated flow[1] that redirects to the RP (equivalent to SP in SAML), which then starts a regular OIDC flow that is indistinguishable from an RP-initiated flow.
This flow is safe against CSRF, since no authentication data is carried together with the flow. The only other safety issue I can see is using target_link_uri for CSF. The spec clearly mentions that this URL has to be filtered or ignored by the RP.
Instead of treating the (horrible) technical implementation as a feature, it addresses the real user-facing feature: I want to be able to click on a link on my IdP dashboard and be redirected to the app. The login would still be seamless, since you already have an SSO session active with the IdP.
I feel like there is an easy solution to login csrf with IdP initiated flows. The SP just gives a pop up saying - you are logging into X as user Y. Continue?
The has been proven again and again to not work. See for example HTTPS certificate warnings for which now there is a standard to ask browsers to not show a popup just saying "The server might not be the correct one. Continue?"
It's an easy solution, but it doesn't work at all.
cameronh90 · · focus · HN ↗
OIDC will eventually displace SAML, but if you're selling to enterprises you should really support both. Both will pale compared to the amount of time you spend dealing with SCIM inconsistencies between IdPs anyway.
maxwellg · · focus · HN ↗
IdPs that need to support an "IdP-initiated" user experience (like a portal or dashboard where users click an app icon) should instead have that icon link to a specific landing page on the SP that safely kicks off a standard, SP-initiated OIDC flow. IdP -> (SP -> IdP -> SP). Look at Okta's "Initiate Login URI" for an example of this.
GICodeWarrior · · focus · HN ↗
The OIDC specification is pretty hand-wavy about how to prevent this attack as well. So don't assume all OIDC implementations do.
unscaled · · focus · HN ↗
This flow is safe against CSRF, since no authentication data is carried together with the flow. The only other safety issue I can see is using target_link_uri for CSF. The spec clearly mentions that this URL has to be filtered or ignored by the RP.
Instead of treating the (horrible) technical implementation as a feature, it addresses the real user-facing feature: I want to be able to click on a link on my IdP dashboard and be redirected to the app. The login would still be seamless, since you already have an SSO session active with the IdP.
[1] <a href="https://openid.net/specs/openid-connect-core-1_0.html#ThirdPartyInitiatedLogin" rel="nofollow">https://openid.net/specs/openid-connect-core-1_0.html#ThirdP...
bawolff · · focus · HN ↗
throwaway7356 · · focus · HN ↗
It's an easy solution, but it doesn't work at all.
bawolff · · focus · HN ↗
For starters, users generally do not understand what a cert validation error means. They do understand what it means to browse to a website.
The cert validation error is in the way of the user's intended action. This popup would not be.
Fundamentally such a pop up is not a security warning. It does not indicate that something is unsafe. That makes a world of difference.
I think a better comparison would be when you exit an app, and the app prompts you if you want to save. That has generally worked well.