[had-rien]

I've been exploring best practices for session storage, and it seems like using HTTP-only cookies the only secure choice. However, I've hit a roadblock when trying to implement a login feature within an iframe, especially with Safari disabling cookie functionality in iframes. This has left me pondering alternatives for secure user authentication within iframes. Has anyone encountered a similar challenge or found a workaround? I'd love to hear your insights and experiences!

[bob1029]

I had a problem with cookies on iOS/safari, so we reached for the last hope: url query args.

Works flawlessly now. If you use an external identity provider, you can hypothetically avoid storing any cookies at all in first party terms. All you'd have would be 3rd party AAD tokens or whatever.

The only reason we even need first party client state is because we want to allow each user simultaneous app sessions that have lifetime decoupled from IdP semantics. This is what we store in the URL query (a guid). Sessions are still bound to user principals, so you would get yelled at if you tried to screenjack someone else's.

[g-b-r]

Keep in mind that urls end up in logs, that might well not be so well protected

[bob1029]

In our case this is fine. The URL doesn't pass any claims. It is opaque client state bound to a specific identity which is validated by other means.

[EE84M3i]

Particularly if you use cdns, tracing, analytics, etc.

Also, IIRC a parent frame can retrieve a child frame's current URL no matter what.