SSO and autologin

[jbm00n]

My apologies if this has already been discussed. I read couple of long threads (e.g. https://github.com/whatwg/html/issues/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

[jbm00n]

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?

[johnwilander]

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?

[jbm00n]

Hi John,

And thank you for your time. I am fairly new to Storage API, so I haven't fully grasp it yet.

1) The first point you explained, is that something in place already or just a proposal? If I understand this correctly, I would think it solves the issue (meaning we configure on our sites the list of domain we owned (and that can be verified) and tell the browser that we are verified with these domains, so let us use the 3rd part cookies. But is that doable?

2) The second point is sort of what I thought Storage API would do. On the first login, via visible iframe, the user would interact with the UI and therefore implicitly tell the browser that "I accept further interactions with this domain". Other calls could then be hidden, and browser would authorize it. But I guess that's not what you had in mind for Storage API?

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.

3) If by "OAuth URL tokens" you mean the regular OAuth standard, then we already do that. Our SSO relies on OAuth. However, OAuth is about reusing a single set of credentials across multiple sites. To enable login in other sites, based on previous login, the SSO site needs to track the user session, to recognize that it already successfully logged in earlier (within this browser session). That's not part of OAuth standard, and requires cookies (or some sort of storage access, which are also being blocked).

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".

[jameshartig]

Regarding the original flow:

1. User visits mybrand1.com and clicks "login"
2. User is redirected (or iframe) to mysso.com, fill up his username/password and logs in
3. User is redirected back to mybrand1.com and is logged in that site
4. User visits mybrand2.com
5. mybrand2.com automatically triggers a "hidden" call (e.g. hidden iframe) to mysso.com to check if user is logged in
6. If so, mysso.com completes the OAuth flow, and returns code/token back to mybrand2.com
7. User is automatically logged in mybrand2.com (and notified with a banner)

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 requestStorageAccess() it would immediately resolve without a user interaction, or is that an implementation detail?

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).

[jbm00n]

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)

[achimschloss]

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

• it would require an additional user interaction to "unlock" access for the SSO providers potentially already available authentication token (3rd Party Context) and that would need to be done for each individual 1st party.
• Given that might not yet exist that would require a second interaction with the user to even start the login process (send them to an OAuth 2.0/OpenID Connect Flow)
• technically this would maybe not be done with iframes, not sure how the API deals with XHR-Requests for example.

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.

[achimschloss]

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:

1. (Prerequisite) - User uses his federated account with any site via a classical OAuth 2.0 Flow (for example medium.com)
2. User visits another site (for example nytimes.com) that uses the same federated login provider and wants to check for existing login status with the federated SSO provider. This is typically done via an XHR Call - at nytimes this call is:

https://accounts.google.com/gsi/status?
 client_id=1005640118348amh5tgkq641oru.....&
 as=SomeRandomValue

3. The result of this call will return if that user has a login state on the device and dependent on that offer the user to register at nytimes using his known account. Below for reference (here using an iFrame based approach)

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:

1. FireFox / Edge (Chromium) this use-case would be possible long term (given the federated login service adheres to the disconnect.me policies on 3rd party requests)
2. Safari with default blocking, it would depend on the details of storage access as of now / other approaches
3. Chrome TBD, to date no problem

Would be good to get feedback on that

[laughinghan]

@jbm00n

Well that was my question, as I don't know how Storage API works.

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.)

[johnwilander]

Sorry for the long delay.

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.

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.

[johnwilander]

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 requestStorageAccess() it would immediately resolve without a user interaction, or is that an implementation detail?

It does not mean that. The user has to interact with a cross-site iframe from mysso.com under mybrand1.com (or mybrand2.com), that iframe has to call document.requestStorageAccess() in an event handler of that interaction, and if the user has not yet opted in to storage access for mysso.com under mybrand1.com, the user will be prompted. If the user has already opted in to storage access for mysso.com under mybrand1.com, the user will not be prompted.

The Mozilla and WebKit policies differ a bit there where Mozilla doesn't require new calls to document.requestStorageAccess() for a period of time after a user has opted in whereas WebKit does. Neither of them keep prompting a user who has already opted in though.

[johnwilander]

I'd be interested to hear if any of the commenters here have thoughts on https://github.com/privacycg/storage-access/issues/83#issuecomment-989205411 and the subsequent discussion in that issue.

[johnwilander]

No more feedback here so I'll close with a reference to https://github.com/privacycg/storage-access/issues/83#issuecomment-989205411.

[johannhof]

Let's close this, please re-open, file a new issue or comment on #83 if there's still interest in this issue.