-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SSO and autologin #16
Comments
Do I understand right that during the "login", the iframe would execute the "requestStorageAccess" (which should work as there is a clear user interaction)? And when the "hidden" iframe wants to check if the user is logged in, we would just call the "hasStorageAccess" (which doesn't require user interaction)? Or did I misunderstand the API? |
Hi! Thanks for filing! The Storage Access API is not intended for invisible cross-site logins. Instead, it's intended for visual, authenticated embeds. However, we do talk about SSO in the Non-Goals section and mention that "the Storage Access API is not in conflict with single sign-on." There are multiple things here. First, a set of domain names owned by one organization which relates to what we proposed as Associated Domains back in 2017 and is now proposed as First Party Sets by Google. Second, the authentication mechanism to the "master domain" and whether that transaction could signal to the browser and/or user that this login is meant to support single sign-on. Third, the authenticating transactions between the "master domain" and the depending websites. As you most probably know, third-party cookies are not the only means of achieving this. OAuth URL tokens are another. And finally, the user experience where browsers what to have cross-site tracking prevention guarantees and the user might not understand that logging in to one website actually logs them in to several websites, some of which they have never seen or used. Do you see the Storage Access API solving or supporting specific parts of this or all of it? |
Hi John, And thank you for your time. I am fairly new to Storage API, so I haven't fully grasp it yet.
Also, does the Storate API, when requesting for access, prompt some sort of browser popup to the end user? If so that might confuse the end user, and they might reject it without understanding what it would actually do.
Now it seems that the Storage API enables that feature, as it will allow to use 3rd party cookies when user has clear interactions. The problem is that we want to take it a step further and autologin without user interactions (other than the initial login of course). Which brings us to your 4th point, which I completely understand, and it's being debate in our company too, as it would avoid end users to constantly click their way through every sites to login (since they already did that once in SSO). Idea is that the SSO site makes it clear that you login in a realm of sites, we also display banners on each site when hidden autologin kicks in. The difficulty I think is because the SSO feature is by nature a tracking mechanism, although it's a friendly, non-malicious one, which makes it hard to fight against "trackers". |
Regarding the original flow:
During step 2, since mysso.com is first-party and has interaction, does that mean that at step 5/6 when mysso.com (as third-party iframe) calls We don't utilize exactly the same flow at the moment but we have plans to offer multi-site web subscriptions and being able to automatically log them into their subscription on a participating site would be beneficial to the user experience there. A similar experience is something like https://scroll.com/ (@kushal). |
Well that was my question, as I don't know how Storage API works. Note that at step 2, if we use the iframe we are in third party, but we also support redirect, so first party is an option (although the user experience is not as good) |
I can only second this here, the scenario of an auto-login into individual sites (without redirects) after a master domain/device login has happened are not really supported by OAuth 2.0 / OpenID Connect, one would use JWT tokens established during the initial login and retain that in the master domain, but the re-use of an existing state after that is different. I don't see how the StorageAccessAPI would help here, as far as I understand
The use case for the user and site operator is to avoid repetitive logins/prompts with federated accounts, that does not look feasible with the API for an auto login scenario. To make that clear, enabling auto-login for a specific site is consent based per individual site, but once the user has chosen to do so it should be respected. SSO providers persist these choices like all others (data transfer approvals etc.) in a server based fashion including privacy controls. |
To make this a bit more concrete, one can take a look at the limited deployment of what was formerly called Google Yolo (One-Tap Sign-In). This used for example with https://nytimes.com or https://medium.com, the mechanics will be similar with other types of services likes this. The idea is to offer the user a way to sign-into a publisher site while re-using an existing authentication state to drive convenience for publishers and users. This is basically a two/three step process:
This is a very viable use case and generally follows the privacy principles of all major browsers and should be supported without adding inconvenience for the user. Both steps 2 and 3 occur in a third party context naturally. In terms of browsers:
Would be good to get feedback on that |
I'm pretty sure the answer is a definite no, hidden/invisible calls to a third-party will not maintain session state, but have you tried testing it? All this stuff has been in production for a while, ITP shipped in Safari in 2017 and the Storage Access API shipped in 2018. (Firefox started blocking third-party cookies for known trackers by default 8 months, and added the Storage Access API 4 months ago, but I assume you're not on the list.) MDN has developer docs for the Storage Access API now, maybe you'll find them more helpful than WebKit's blogpost. I found the detailed differences between Safari and Firefox's implementations particularly enlightening. (From my understanding, if you were on the known tracker list, your hidden/invisible SSO calls would break in Firefox, too.) |
Sorry for the long delay.
My understanding of the login scenario you describe is that the identity provider (IP) is able to identify the user under the Relying Party (RP) by the user merely browsing to the RP and without explicit user opt-in under that RP. That does not follow WebKit's Tracking Prevention Policy and I doubt it follows the Mozilla one either. I do not agree that there is anything in web standards that says this should or has to be be supported. |
It does not mean that. The user has to interact with a cross-site iframe from The Mozilla and WebKit policies differ a bit there where Mozilla doesn't require new calls to |
I'd be interested to hear if any of the commenters here have thoughts on #83 (comment) and the subsequent discussion in that issue. |
No more feedback here so I'll close with a reference to #83 (comment). |
Let's close this, please re-open, file a new issue or comment on #83 if there's still interest in this issue. |
My apologies if this has already been discussed. I read couple of long threads (e.g. whatwg/html#3338) and I just wanted to check the situation with SSO flows.
We basically have the similar case as mentioned by people from Auth0 (in that above thread).
Our organization owns multiple brands, and allow users to access these brands' sites with a single account, via SSO.
The flow is this:
User visits mybrand1.com and clicks "login"
User is redirected (or iframe) to mysso.com, fill up his username/password and logs in
User is redirected back to mybrand1.com and is logged in that site
User visits mybrand2.com
mybrand2.com automatically triggers a "hidden" call (e.g. hidden iframe) to mysso.com to check if user is logged in
If so, mysso.com completes the OAuth flow, and returns code/token back to mybrand2.com
User is automatically logged in mybrand2.com (and notified with a banner)
Would the Storage API allow such flow? It's still a bit confusing to me when user "interaction" is required.
Thank you for your time
The text was updated successfully, but these errors were encountered: