5 ms·

We have an on-going issue with Apple's protections going back almost a decade to when they started mucking about with 3rd Party Cookies. This isn't entirely th

We have an on-going issue with Apple's protections going back almost a decade to when they started mucking about with 3rd Party Cookies. This isn't entirely their fault, blame also lies with the vendor we've chosen and our architecture for SSO. That being said, there are valid use cases for tracking users across websites. I work for a nonprofit that does fundraising using every imaginable PaaS or SaaS platform as well as quite a few in-house developed tools. We offer an SSO experience across all of these various platforms and integration is a nightmare. OpenIDC, OAuth, SAML, ADFS, and lots of custom APIs. It works for the most part everywhere except Safari where a few of our integrations just cannot and will not work due to their use of 3rd Party Cookies. Fortunately the way we've had to structure our solution, Sign in with Apple won't be much if any disruption to the status quo. It won't however help matters either.

zchrykng 7y ago
Definitely a situation of non-nefarious uses getting nuked along with the nefarious ones. Not sure I would really blame Apple as much as all the horrible people who made it necessary for Apple to build this. They probably should allow more fine grained controls, something like "I know and trust these websites, don't nuke their cookies all the time" setting.
- cptskippy 7y ago
  > Not sure I would really blame Apple I don't. They have their users best interests at heart and their solutions have always left the functionality we needed there but that still doesn't mean they haven't been a thorn in my side by evolving their platforms.
frenchyatwork 7y ago
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.
adamlett 7y ago
That being said, there are valid use cases for tracking users across websites. Strong disagree. It works for the most part everywhere except Safari where a few of our integrations just cannot and will not work due to their use of 3rd Party Cookies. It sucks to have sunk so much time and effort into a solution only to have external factors render it unworkable, and I feel for you. But it is entirely possible to implement SSO across multiple domains without relying on 3rd party cookies. I know because we use Apereo CAS, which is one such solution at my company. https://www.apereo.org/projects/cas https://www.apereo.org/projects/cas
- wolco 7y ago
  Of course it's easy and we all have a fav sso projects but if you do not control the code it may not be possible
- cptskippy 7y ago
  > But it is entirely possible to implement SSO across multiple domains without relying on 3rd party cookies. Yes it is, especially when you green field or have full control over the products. However there are times you do not have a lot of options when integrating with a vendor. Of course you can say "well choose another vendor" but that's not always up to you. Especially when you're dealing with legacy integrations.
chrispeel 7y ago
> That being said, there are valid use cases for tracking users across websites. I work for a nonprofit ... Could you explain "valid use" more? I hope that you're not implying that we should allow all non-profits to track people across websites so they can do fundraising.
- wolco 7y ago
  They have three domains and want one sign-in on one domain to login to all three. Normally they write a cookie the other domains can read.
- cptskippy 7y ago
  Well in our case we have multiple fundraising tools provided by a myriad of vendors (greater than 10). These tools vary in architecture (e.g. SaaS, PaaS, Turnkey, etc) and age. We also have a number of in-house developed products. We also have training resources that are exposed in different ways from Salesforce Communities to LMS based training systems. Our fundraisers and constituents as a whole have access to these tools to interact with us. Some of the products are self service, others require authorization. All of them are branded and the users consider that they're interacting with us and not the underlying product. So we have a situation where we need to Authenticate a user and possibly authorize them to access tools with varying roles and degrees of access. If a user needs access to Tool A but can't until they've completed training in the LMS, we have a situation where we need to identify and track a user across disparate platforms. It's not unlike having a Microsoft Account shared across Azure, DevOps, Office 365, and TechNet. Or a single Google Account to access Drive, Developer APIs, and Gmail.
- withinboredom 7y ago
  At WordPress.com, we have millions of sites. Having users be logged in so they can ‘like’ a post or comment or write new content is kinda important. That uses APIs and third party cookies (first party, but the API is a third-party from the perspective of the site they’re on). We are constantly dealing with Safari thinking it’s “tracking”. Disclaimer, we do track things, but only on admin pages, not users’ sites.

zchrykng 7y ago

Definitely a situation of non-nefarious uses getting nuked along with the nefarious ones. Not sure I would really blame Apple as much as all the horrible people who made it necessary for Apple to build this. They probably should allow more fine grained controls, something like "I know and trust these websites, don't nuke their cookies all the time" setting.

cptskippy 7y ago
> Not sure I would really blame Apple I don't. They have their users best interests at heart and their solutions have always left the functionality we needed there but that still doesn't mean they haven't been a thorn in my side by evolving their platforms.

frenchyatwork 7y ago

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.

adamlett 7y ago

That being said, there are valid use cases for tracking users across websites. Strong disagree. It works for the most part everywhere except Safari where a few of our integrations just cannot and will not work due to their use of 3rd Party Cookies. It sucks to have sunk so much time and effort into a solution only to have external factors render it unworkable, and I feel for you. But it is entirely possible to implement SSO across multiple domains without relying on 3rd party cookies. I know because we use Apereo CAS, which is one such solution at my company. https://www.apereo.org/projects/cas https://www.apereo.org/projects/cas

wolco 7y ago
Of course it's easy and we all have a fav sso projects but if you do not control the code it may not be possible
cptskippy 7y ago
> But it is entirely possible to implement SSO across multiple domains without relying on 3rd party cookies. Yes it is, especially when you green field or have full control over the products. However there are times you do not have a lot of options when integrating with a vendor. Of course you can say "well choose another vendor" but that's not always up to you. Especially when you're dealing with legacy integrations.

chrispeel 7y ago

> That being said, there are valid use cases for tracking users across websites. I work for a nonprofit ... Could you explain "valid use" more? I hope that you're not implying that we should allow all non-profits to track people across websites so they can do fundraising.

wolco 7y ago
They have three domains and want one sign-in on one domain to login to all three. Normally they write a cookie the other domains can read.
cptskippy 7y ago
Well in our case we have multiple fundraising tools provided by a myriad of vendors (greater than 10). These tools vary in architecture (e.g. SaaS, PaaS, Turnkey, etc) and age. We also have a number of in-house developed products. We also have training resources that are exposed in different ways from Salesforce Communities to LMS based training systems. Our fundraisers and constituents as a whole have access to these tools to interact with us. Some of the products are self service, others require authorization. All of them are branded and the users consider that they're interacting with us and not the underlying product. So we have a situation where we need to Authenticate a user and possibly authorize them to access tools with varying roles and degrees of access. If a user needs access to Tool A but can't until they've completed training in the LMS, we have a situation where we need to identify and track a user across disparate platforms. It's not unlike having a Microsoft Account shared across Azure, DevOps, Office 365, and TechNet. Or a single Google Account to access Drive, Developer APIs, and Gmail.
withinboredom 7y ago
At WordPress.com, we have millions of sites. Having users be logged in so they can ‘like’ a post or comment or write new content is kinda important. That uses APIs and third party cookies (first party, but the API is a third-party from the perspective of the site they’re on). We are constantly dealing with Safari thinking it’s “tracking”. Disclaimer, we do track things, but only on admin pages, not users’ sites.