Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Simpler UX for OAuth2 login with GitHub #3837
UX Review: Current Behavior
I have enabled OAuth2 for GitHub
I’ve also changed my theme so that Login with GitHub is prominent.
When a user clicks to Login with GitHub (or any OAuth2 provider) for the first time, they are dropped at a screen that asks them to login or create an account.
I’ve watched people then attempt to sign in using their GitHub username and password because it isn’t clear to them that they’re continuing an account creation process.
I think that this could be simplified if the Login / Create Account page were laid out side-by-side, or if the order were reversed.
Better yet, have them enter their email or login, then click “next” and then, based on whether or not that account exists, present them with the appropriate “login” or “create account” screen.
I’m going to try and get some help from a friend of mine who does frontend to modify the theme and provide a suggestion and potentially a pull request.
Templates for Reference
The "inner" templates are also used on these pages:
I'll post back with another screenshot once I modify the template.
Although it'll be quick to modify the template as an interim solution, I think the best solution will be to change the flow - similar to what Google, Slack, and others do:
@larshp The problem is that github routinely goes down from DDOS attacks.
That's one of the benefits of using a self-hosted git solution.
What we really need is federated authentication, but that doesn't exist yet. There's no financial incentive for a large company to develop an open protocol (i.e. email) that a competitor could use. Instead, protocols with built to preserve vendor lock-in (like OAuth2) ensure their creator's survival (i.e. Facebook). Then there are some valiant efforts from non-profits like Mozilla, but the solutions that they come up with are too politically charged (i.e. ads are evil, non-anonymity is evil, etc - more about why it's politically morally superior than the benefit to the user) and/or geeky (requiring manual steps, like OpenID) to make it into mainstream.
referenced this issue
May 18, 2018
My friend didn't quite understand the purpose of the current flow either. I explained it to him like this and he understood it better:
This sounds like a great use case for IndieAuth. https://www.w3.org/TR/indieauth/
IndieAuth is an OAuth 2.0 extension, which avoids the centralized problems with existing OAuth solutions by using DNS for "registration" of client IDs and user IDs. Every user account is identified by a URL (for Gitea this could be your Gitea user page), and client IDs are also URLs (would be the Gitea instance home page in this case.)
To log in to your Gitea instance, I would enter my own Gitea profile URL. Your instance would then do discovery on my URL to find where to send me to authorize the login on my own OAuth server (my Gitea server), which would then send me back to your Gitea where it would be able to verify the authorization code against my Gitea instance.
I'd be happy to walk through this in more detail if you're interested!
I think IndieAuth makes a lot of sense as the way to implement a federated login protocol to provide a "simpler UX for OAuth2" login for Gitea as this issue is named.
It would also be possible to provide support for the "with GitHub" portion (as originally noted in the issue) without having to ask / wait for GitHub to implement IndieAuth, by adding https://indieweb.org/RelMeAuth support.
https://indielogin.com/ is an example of an open source service that supports both of those, IndieAuth as @aaronpk suggested and RelMeAuth, and is in daily use by folks signing-into the IndieWeb.org site.
(Originally published at: http://tantek.com/2018/155/t1/)
I ran into this today and I find it very confusing that oauth requires users to type in a password and captcha for their account. Additionally, clicking the "sign in with ___" button makes it unclear whether I'm going to have the option of linking with an existing account.
IMHO, we should be able to disable captcha and password requirements for oauth-created accounts, so that you can have an empty password need be. It might also be beneficial to allow clearing passwords if you use oauth, so that you really don't have a password managed by your gitea account, and just from this external provider.
Here's a post I just wrote explaining IndieAuth and how it solves a number of the challenges with OAuth in this context.
@jhabdas I wouldn't.
Total tangent, but here goes...
All Authentication Sucks
For years I've been working on a protocol I call OAuth3 (but I'd like to come up with a better name). It's like a peer version of OIDC or a convenient version of IndieAuth.
However, there have been a number of roadblocks and challenges. Having something work peer-to-peer (decentralized) and be convenient, is neigh unto impossible (but it is possible).
The problem with all existing auth solutions is that they're in one of two camps: Proprietary/Centralized (OAuth2 implementations) or complicated for a non-technical user OpenID/IndieAuth.
What Could Succeed
The way I believe that peer authentication will succeed is by providing a solution that primarily executes on the client device (keypair authentication) but, by default, syncs the public keys to a shared server (with a centralized well-known server as the default), and uses a static page (or 3rd party app if on a phone) - no server APIs required to function - in essentially the way a browser plugin (or native Facebook/Google OAuth on phones) works to manage the exchanges.
Ultimately, browsers need to adopt such a protocol, but it most be open and compatible between browsers. The same is true for smart phones. Until then, the centralized server would serve as a "broker" to serve the user's preferences to other client-side apps.
Most importantly, people need to be able to login like they're used to. It must be easier than the current solutions, not more difficult (and how better to make it easier than by removing the most frustrating - and least secure - part of login: passwords).
What it might look like
First Login on a Device
Secondary Login on Device
But That's not a PERFECT Solution!
If you're on one side of a chasm and you want to migrate a host of people to the other side, you need a bridge. Something like generic-auth.org (in the hypothetical scenario above) acts as that bridge. The migration would be complete when browsers and phones natively support open-protocol peer-based authentication that doesn't require 3rd party apps to bridge the gap anymore (like how Chrome has proprietary Google auth implemented).
Until that time you have the problem of OpenID/IndieAuth if you go for the "Perfect" peer solution - it requires too much knowledge and effort to intentionally use it. My mom is unlikely to create a website and link it to her other accounts with HTML tags.
The truly "perfect" solution then is the solution that people who don't care about technology and who don't understand the risks with their current login and authentication setups will adopt out of convenience, and perhaps a sense of individuality or pride, but certainly not for being the most technically correct solution.
Peer-to-Peer can either be convenient for end-users or convenient to develop. It simply can't be both.
You've basically described IndieAuth, but using
Email addresses are URLs too. If you assume an
I made that site send an HTTP redirect to my actual website, so I can log in with my email address anywhere that uses IndieAuth right now.
Supporting two-factor auth, or passwordless auth is entirely up to the IndieAuth server, as it's not part of the federation spec. In fact, I already have passwordless login to my website using a push notification to my phone which works with every IndieAuth client already because the clients don't care how I authenticate to my website, just that I do authenticate.
As for your point about the bridge, anyone can create a generic IndieAuth provider that provides identities to anyone who wants one and doesn't care about owning their identity. They enter
Perhaps that's not at all related to "IndieAuth" that we're talking about here (I didn't read your article yet, but I will now).
Yeah sorry for the confusion. I've started the (very slow) process of shutting down
Please do check out the blog post, it does a much better job of explaining the actual goals and motivations of the spec.
There is no need for requesting a password to be created. It can be set to something random and later set via email reset if necessary.
This is what needs to be communicated:
What I think would be best, in all cases, is to ignore the password altogether and simplify to a single flow across the board:
Again no password needed.
In fact, passwords only add vulnerability to a web application. Without a password a person's account can be compromised via email. With a password the account can be compromised via any number of publicly available username/password lists, and still via their email. Passwords are a weak link that corrupts any chain you put them in (unless the password is a secondary authentication rather than a primary authentication - such as requiring it to make account changes after 15 minutes of inactivity).
@lunny that could be handled by showing the user a device code and instructing them to use
Or they could create a password and be warned that a password reduces the security of their account.
However, the password issue as not as pressing or as easy to fix as the original issue that the current create account page is really confusing for people trying to login with GitHub.
I tried try.gitea.io and I've noticed this issue as well: it's confusing that gitea requires one to choose a local password even when authentication is done with an external account. (The other possibility, "linking", is, if I understand correctly, to entrust one's password at the other service with the gitea instance - this seems outright dangerous!)
On our gitlab server, we regularly get contributions (e.g. issues are opened) by people who log in with their github or google account. Doing the same with gitea is too complicated and creates too much of a barrier for one-of-a-time contributors.
@coolaj86, that's reassuring, thank you for the explaination. Let me explain why I was confused.
When a new user signs in to try.gitea.io using a github account, a page shows up with the instructions: "Sign in with existing credentials to link your existing account to this account. Or register a new one." Below, two boxes are visible, one with the title "sign in", the other one "register". The first box clearly corresponds to the first option "sign in with existing credentials", and to me that meant "with existing github credentials", even more so because my github username was already filled-in!
Now, thanks to your explaination, I understand that "sign in" in the above case means: sign in with a previously created local gitea account and link it to the github account. IMHO this is not at all clear to a new user.
If you ask me, the action of linking an existing gitea account should be moved to the settings section of gitea. I also believe that the registering of a new account should be automatic with a random password, that can be changed later if necessary.
A naive approach to the "account linking problem" can be to look for a local user with the same email address or username and ask the user for actions in that event.
I proposed setting the password to a random value only because I expected that would be simpler to implement. Disabling local sign-in and http(s) is cleaner, but both should have the same consequences in practice. Good point also about the case where a user has a local account but has forgotten about it.
This was referenced
Oct 6, 2018
Okay, I've got something that's ready to test (I'd say the 20% of the work that provides 80% of the most important solutions)
See it in action
I've got it running on my gitea instance at https://git.coolaj86.com
If you'd like to test it out for yourself
git clone https://github.com/coolaj86/gitea.git gitea.coolaj86 -b v1.5.1-coolaj86 pushd gitea.coolaj86 TAGS="bindata sqlite" make generate all
I would not recommend replacing your existing gitea, but rather creating a symlink so that you can easily switch back if you don't like it. For example, if you keep
rsync -av ./gitea /opt/gitea/bin/gitea-v1.5.1-coolaj86 pushd /opt/gitea/bin mv gitea gitea-v1.5.1 ln -s gitea-v1.5.1-coolaj86 gitea
I've run a couple of manual tests so far, so I feel comfortable with someone else trying it out. I won't be pushing any additional changes to that branch (such as the upcoming changes to address the empty checkboxes in the issue) until I've tested them in production for myself.
AJ ONeal wrote:
Okay, I've got something that's ready to test (I'd say the 20% of the work that provides 80% of the most important solutions)
I just tested it. It's a clear improvement, thanks! I noticed an incosistency: During the intial sign-in process, when one returns from github to gitea, a form is shown with the title "Add Email and Password (for Account Recovery)" However, the only two text fields are "username" and "email address". Shouldn't the title be rather "Add email address (for account recovery)" ?
@grothesque Good catch.
I made each PR independent from the other so that they could be accepted as small changes, without any merge conflicts, rather than a lump change.
Because of that, I updated the wording in one PR, but not in the other that also modified the same template.
I’ll see if I can find better wording that will apply to both equally well and add a commit for it.