3 ms·

I don't know about the plaforms you're working with, but I'm pretty sure 3rd party cookies shouldn't be necessary for OpenIDC. They certainly weren't for OpenID

I don't know about the plaforms you're working with, but I'm pretty sure 3rd party cookies shouldn't be necessary for OpenIDC. They certainly weren't for OpenID. If it's a problem, it's probably because of the specific platform intentionally did things in a way that was bad for user's privacy. Unfortunately, non-profits I've seen tend to be really bad at privacy because they need to a) keep things cheap and b) have a significant presence on advertisement platforms.

cptskippy 7y ago
I think you missed what I'm saying, we don't get a choice. We integrate with the best option we can from a given vendor at the time. And we don't always have the luxury to go back and refactor architectures. We have integrations we setup 10 years ago that are still functional today, and there's no valid business case to touch them until they break. Some vendors use OpenIDC, others use SAML, others use OAuth, some even use WS-Trust, while quite a few use custom authentication based off something Google did in 2006. Many say they support OpenIDC, SAML, or OAuth when in reality they have something loosely resembling those protocols. The landscape has changed a lot in the 15 years I've been mucking about in identity. Entire industries were born to deal with the fact that Google, Facebook, Microsoft, and Yahoo! couldn't keep their authentication APIs stable for more than 2 months at a time. 10 years ago you signed up with Gigya, JanRain or Ping so that you didn't need a team of developers to actively maintain your SSO integrations with 3rd parties.