3 ms·

I'm a cofounder of https://clerk.dev https://clerk.dev and we've found we need to keep a close eye on this ever-evolving world of browser security models. I th

I'm a cofounder of https://clerk.dev https://clerk.dev and we've found we need to keep a close eye on this ever-evolving world of browser security models. I think what OP has glazed over a little bit, is that authentication is a massive, thorny exception to their advice of "adopt the Same Origin Policy instead." Consider these authentication use cases: - Sharing sessions across mail.google.com and drive.google.com - Sharing sessions across google.com and youtube.com - An okta.com generating a session on google.com - Persisting a youtube.com session even when youtube.com is in an iframe on example.com All of these scenarios are reasonable, but it's a huge challenge to support all of them in a privacy- and security-conscious way. That being said, I generally agree with the advice of "adopt the Same Origin Policy instead" after authentication is solved.

methyl 5y ago
Authentication is a huge problem for us, as we integrate with other platforms via an iframe. When people disable 3rd party cookies, it's impossible to authenticate users between two unrelated domains. And there is no alternative I'm aware of.
- IX-103 5y ago
  Yes, that's a known problem. The only proposed solution I've seen so far is Fenced Frames (https://github.com/shivanigithub/fenced-frame https://github.com/shivanigithub/fenced-frame). I don't know if that would even work in your use case, as it's still very limited.
  - thayne 5y ago
    From what I can tell, the fenced frames wouldn't work for certain kinds of integrations, where the iframe needs to both communicate with the host page via an integration api and be authenticated for its own domain.