-
-
Notifications
You must be signed in to change notification settings - Fork 5.4k
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
Simpler UX for OAuth2 login with GitHub #3837
Comments
Any suggestions what to change? |
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:
|
Suggest not asking the user for setting a recovery password. If signing in with GitHub, I guess GitHub is responsible for the recovery process if needed? OAuth is a great way to get rid of passwords for smaller sites. |
@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. |
For reference: 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. |
@coolaj86 how would you describe IndieAuth to your friend? |
Here's a post I just wrote explaining IndieAuth and how it solves a number of the challenges with OAuth in this context. https://aaronparecki.com/2018/07/07/7/oauth-for-the-open-web |
@jhabdas I wouldn't. Total tangent, but here goes... All Authentication SucksFor 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 SucceedThe 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 likeFirst Login on a Device
Secondary Login on Device
Logout
Security
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. The Catch-22Peer-to-Peer can either be convenient for end-users or convenient to develop. It simply can't be both. The saving grace is that if it's implemented in JavaScript and used in native apps through a web view, we only need a single implementation for the client-side and only 3 to 5 APIs for the server side (sync public keys, send email / push notifications, sync pairwise grants) - none of which require knowing anything about security or keypair signing and encryption - just opaque files, simple messages, and plain-old JSON. |
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 |
@aaronpk Perhaps I misunderstood and need to read carefully. Perusing https://indieauth.com/ what I got was "This is a reboot of OpenID that requires you to create a webpage and link to it". 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. |
I'm not sure what's going on here. |
@pkit local user needs to be created anyway or otherwise how would you reference/add rights etc for it if it is not saved? |
@lafriks I think it's not necessary to create a "complete" local user. E.g. the user doesn't necessarily need a password if he gives up using https protocol. |
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). |
If no password enabled, user should be denied when clone or push via http/https |
@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. |
@coolaj86 Yes, I agree with you. |
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. |
@grothesque "linking" just means that you enable multiple styles of login. People may pick the same password, but that is not the intent. |
@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. |
@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. |
As it currently stands, you cannot delete your account without sending a password-reset request to your backup email. |
I suggest we request confirmations by email rather than by password
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions. |
I too would love to see this merged! I was halfway through writing my own modifications when I found this thread and the version mentioned earlier seems perfect. Any idea when the pull requests might be merged? Being able to use the releases without maintaining local patches and building from source every time there is a release would be a huge benefit in my opinion. |
@lgommans, @clarfon, @ix5, @strk, @grothesque I'm reworking my original PR set so that it will apply against v1.9-dev. I would love to have some help if you have a few hours. Any two of us could pair for a little bit and then split up to conquer and test. The work consists of manually going through the old PR, finding the new place where things go (as there has been some refactoring), and working it back in. I'm open to any technology, but if you sent me and email (important) and then opened a gchat / google hangouts with me, that seems to work well enough: coolaj86@gmail.com |
@solderjs I sent you an email ~25 minutes ago, not sure if it ended up in spam maybe? (Gmail's filters are rather aggressive) Edit 23:12 CET/UTC+2: I'm going to go sleep soon. If you would still like to collaborate, drop me an email and mention a time between 11:00-20:00 CET for tomorrow (Sunday) :) |
@lgommans I check my email manually because if I had notifications on my phone would be buzzing every few minutes all day long. I'm in MST. I can't make tomorrow work because I'll asleep when you're first available and just getting out of church when you're no longer available, but I'll keep in touch and find a time that works. If I'm already done with this PR, I'm sure that there will be another to work on soon. |
Testers WantedI've got everything rebased. It would be great if a few people other than myself could build from through this branch and identify issues, if any: https://github.com/solderjs/gitea/tree/ux-master Live Site |
Works! Steps I took:
[1] 2019/04/14 11:03:02 routers/user/auth.go:595:handleOAuth2SignIn() [E] UserSignIn: could not find a matching session for this request So in summary:
I'm also wondering if there is any reason the email address is still required. The purpose is account recovery, but if someone doesn't want that, we could make it an optional field and let it default (on empty submission) to something that will never exist like Thanks for all the work on this! Edit: I just noticed that, to delete your account, you need to enter your password. Since no password was set, this is not possible. I guess the flow here is to do a password reset? Do we want to add a message like "perform a password reset to obtain a password for your account" in the account deletion section if no password is set for the account? I tested doing a password reset and deleting the account, that indeed works. Trying to sign in again after that, I get the same error as before: 2019/04/14 12:18:44 routers/user/auth.go:595:handleOAuth2SignIn() [E] UserSignIn: could not find a matching session for this request This time I did go through the proper login screens, so that does not seem to be the cause. Retrying, same behaviour as before: this time it works and i get to the 'account recovery setup' screen. |
500I haven't been able to nail down the source of the 500. I also haven't been able to reliably reproduce it. Are you saying that you get it every time a new user signs up, even when the server hasn't been rebooted? Are you also saying that you only get it when clicking the direct link in the nav bar next to sign in, but not when clicking it from the sign up page? I'm thinking as a hack I could just have the user redirected to a special page that clicks the login button for them a second time. I'd love help solving this. IPv6I didn't make in changes in that area. Email AddressThere does need to be some sort of local identifier by which accounts can be linked and to which notifications can be sent. In any case, it would be high complexity to create an account without one with the current codebase. |
Testing some more, I can reliably reproduce the 500 when using private navigation. The first time I go through the flow, i.e. with no cookies already set, it fails. I noticed that in the redirect to Github, it sets a cookie, The error I see in the logs appears in two places in the source code: in I can't reproduce it on your system. Not sure what the difference is, but the browser just returns the gothic cookie (though your system also sets it with "Expires: 2019-04-right:this:second"). Do you have any idea? It seems really strange behaviour on gothic's part anyway, setting a cookie that expires right now, but which it still needs... |
@lgommans could you send a PR to upstream to fix that? |
@lunny I don't know the code well enough to tell whether this is an issue on ghotic's side, on gitea's side, or even on my side (since soldierjs' hosted version does not have the issue). I can hardly read Go code so for me it would take hours to track this down. Someone familiar with the code can probably track down a session bug in a few minutes, at least to figure out if it's an issue in the library or in gitea. |
Just setup gitea for internal use with our own openid provider and I was very confused by this. The point of openid for us is to remove the need for login (in fact, we would much prefer gitea not have a login form at all). What we did in our case (but is very confusing) is connect gitea to both openid and ldap while disabling registration. That way the user cannot create a local password and has to link to their ldap account. This way they are still able to update their password directly in the ldap and have it take effect in gitea. The first connection of a new user is really confusing (after that, SSO does its magic and they never have to fill a form again). What we would like:
With those points in place, the login flow on gitea's side can be entirely transparent with the user seeing exactly none of it. |
@bendem I think this thread is more about GitHub login integration, not sure if there is another ticket where general oauth/ldap integration/UX is more fitting or if it would fit better in a new one. (I'm not any sort of moderator by the way, just observing.) |
with auto account create and other oauth2 improvements you now should be able to do as you propose :) |
UX Review: Current Behavior
Long Read
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
Potential Conflicts
The "inner" templates are also used on these pages:
The text was updated successfully, but these errors were encountered: