Due to upcoming changes to how browsers handle cookies we will need to send users to a different domain to log in. The platform team has a demo running on how this might work.
There was a request for design to review this design and user flow and provide a review with any recommendations.
There are two design aspects of this (that I'm aware of right now). One is the one that has been discussed, that we might want to replace the fullscreen login form with a popup or iframe modal. The other is that the URL used to share cookies will become user-visible (unless we go with the iframe modal, which has technical disadvantages). So when interacting with the login form, the user will see something like https://sso.wikimedia.org/en.wikipedia.org/wiki/Special:Userlogin which is potentially confusing or suspicious ("wikimedia.org" has limited brand recognition compared to "wikipedia.org", technically sophisticated users will maybe think the presence of en.wikipedia.org (used to identify from which wiki the user started the login process) is a phishing trick).
Can we just use numeric ids or short hashes that map to the various project domains?
We would have to maintain another mapping (besides domain <=> DB name and domain <=> site/lang) then. Other than that, it's straightforward.
My guess would be that technically sophisticated users are able to link wikimedia.org with Wikipedia given that we already load resources from wikimedia.org (CentralNotice, Commons images, etc.) on every request (previously also bits.wikimedia.org). I think if we're worried about phishing concerns, which is reasonable, it would be good to avoid acronyms and jargon like "sso" and use a more accessible term "login" or "accounts" (hopefully I'm not trying to re-open a closed bikeshed).
It's an open bikeshed! Others have recommended suggested "accounts" too. (login.wikimedia.org is already in use.) It's more understandable but also not very accurate since the domain will not be used for account management in general.
well if the shed is open... could SSO be de-acronymed to single-sign-on.wikimedia.org?
Yeah we could do that. Or we could use something like authentication.wikimedia.org.
We'll go with "sso" for the Beta cluster version (T365162) since the code is already written for that, but it's trivial to change later. We won't need to settle on a final name for a while, since deciding T363695 will take some time; at this point it's also possible we won't be able to use a new domain at all, and will use login.wikimedia.org with a very different implementation. So not worth spending too much effort on the name yet. But we'll circle back once we are certain a new domain is needed, since the naming seems like primarily a UX question.
Alternatively we can just use login.wikimedia.org with a different code path like https://login.wikimedia.org/login/enwiki
I’d like to come to a final decision on the domain and it looks like this is the task with the most previous discussion, so to continue…
There are two parts to this: 1) The authentication domain 2) The wiki identifier.
Authentication domain
For traffic routing reasons, it is difficult to reuse the existing login.mediawiki.org domain and for development sso.wikimedia.org was used as an alternative. There are concerns that this is too opaque for users due to the technical acronym. I think there are three alternatives:
If we want to start to move in a direction towards Wikimedia accounts, then the third option is desirable, however using that domain now may make it harder to reuse in the future. Given this is restricted to authentication for now, with other account pages remaining on-wiki, that suggests that option one or two is more appropriate. The extension is also called CentralAuth, which makes that term perhaps more broadly understood by people who are more likely to look closely at the URL.
Wiki identifier
Currently the source wiki for the authentication request is included as first path part in the URL:
https://sso.wikimedia.org/en.wikipedia.org/wiki/Special:Userlogin
There are concerns that this obfuscates the real domain and so could look like a phishing attempt. My preference here would be a query parameter that makes the relationship to the original domain clear, eg usewiki=enwiki or sourcewiki=enwiki, but there are technical considerations that make that harder to achieve than a path part.
That suggests to me that the pragmatic option is to use the wiki id as the first path part, either directly or base64url encoded:
https://auth.wikimedia.org/enwiki/wiki/Special:Userlogin
https://auth.wikimedia.org/ZW53aWtp/wiki/Special:Userlogin
@RHo, @mwilliams, @sbassett, I’m particularly interested in the UX and Security considerations here and your thoughts on the options above. Thanks.
Consumer hat: most people esp non native english speakers and non techies in general, don’t know what ‘auth’ ‘authentication’ or ‘sso’ means, as opposed to login or ‘account’ or even ‘user’
Thanks for this Jonathan! My main priority is to make sure the URL feels trustworthy...simple, clear, and familiar. Sticking to something very close to what we currently use for consistency and familiarity also seems like a good path forward.
Before chatting with you about the constraints the obvious and simple answer felt like login.wikimedia.org with the source wiki as a possible addition in the query parameter. I'm curious how difficult it would be to go in that direction. e.g. It's possible but would add multiple weeks to the implementation, etc.
Between the options you suggested, I’d lean toward https://auth.wikimedia.org/enwiki/wiki/Special:Userloginover the base64url option, which seems less readable and potentially more “phishy” due to the encoded characters. "Auth" is slightly better than "SSO", but agree that most people probably won't know what it means either.
Personally, I'm not sure I see an enormous issue with sso.wikimedia.org. The other proposed options seem a bit too vague to me for what SUL3 is actually trying to accomplish.
Agree with @mwilliams about the non-base64url option, which is hard to read at best and comes off phishy at worst.
Out of authentication domain options, would also go with the option most understandable by the most people, which @TheDJ would be non-english and non-tech folks would be account.wikimedia.org, followed by authentication.wikimedia.org. While Auth is shorter, my assumption is that not that many people are going to be typing out the URL so it seems marginally better to have the whole word for clarity.
Thanks for all the input @Bugreporter @TheDJ @mwilliams @sbassett @RHo.
Authentication domain
The broad consensus is that the domain should be reflective of the actual purpose, which is strictly the authentication part of single sign on (c.f. authorization, user attributes and user management). It should also be as understandable as possible. For me this rules out both account.wikimedia.org and sso.wikimedia.org.
Best practices across the industry appear to favour login or auth for custom domains: Auth0, WorkOS, AWS Cognito, SSOReady, FusionAuth.
Given we can't use login.wikimedia.org as it hosts loginwiki, let's go for auth.wikimedia.org.
Wiki identifier
There is a clear consensus for for using the wiki id as the first path part, as plain text. So let's go for that.
That gives our final URLs the form:
https://auth.wikimedia.org/enwiki/wiki/Special:Userlogin
We'll reflect this change before we push to the test wikis.