For reference, this is the screen that has confused several people:

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:

• 1a. Let the user know that they were successful: Thanks for signing in with [[sso provider]], [[username]].
• 1b. Ask the user for their email address: "Please input your email address:"
• 1c. The user clicks "Next".
• 2a. On submit check if the user exists or not, then display the appropriate options:
• 2*. (some claim this is a security vulnerability, but that's bogus as you can test for the existence of the user in many ways and the the user isn't private anyway)
• 2b. Ask the user for their password depending on whether or not they exist in the system
  
  
  
  • "Please enter your [[sitename]] password" (as to avoid confusion with their [[sso provider]] password).
  
  
  • "Please create a password for [[sitename]]" (or, for security, let people disable passwords for security and set up 2FA instead - such as "QR Code" or "Magic Link"). Also display the captcha.
  
  
  • Or "Enter or create your password" if the "security" measure of not being able to probe an account name is being held to, and only show the capcha afterwards
  
  
• 2c. The user clicks "login" or "create account"

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:

You’re half-logged in. You are “authenticated”, but not “authorized”.

You’ve gone through the TSA security check, but you have to do a gate check at the _correct_ gate to be boarded on the plane.

The service knows that your ID is a valid ID, but it doesn’t know what that ID is good for.

Like it can see you have a Utah Drivers License, but it doesn’t know what your phone number or email address is, so it still can’t connect with you.

Or as if you called up the electric company and told them your passport number, and you have an account with them, but your passport number isn’t actually on file so the still need your name and account number even if they validate your identity by the passport number.

The question remains “which things on this service belong to you?” and by linking the account you’re saying “oh, you’ve seen me before, but you knew me by my email, not my GitHub name. These things by this email are what belong to me” and if you create a new account you’re saying “nothing, this is my first time here, so let’s get my ID linked to a new account”

In either case, next time around it knows what your GitHub ID relates to on the local system.

What we really need is federated authentication, but that doesn't exist yet.

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

1. I click "Login"
2. A pop-up to "generic-auth.org" opens up (better branding, but you get the idea)
3. The user types in their email address (or domain name)
4. The part after the '@' (if email) is checked for a /.well-known/peer-auth/index.json
   
   
   
   • on 200 OK, redirect to that with ?subject={email} for the next step and save the user's choice
   
   
   • on 404 continue using generic-auth.org
   
   
5. I get a push notification on my device (or an email with a "magic link")
   
   
   
   • also, generic-auth.org could link to facebook, twitter, google, etc (though a true peer-auth site could not as that would require having a developer account)
   
   
6. I click the link in email (or the "Allow" option on the push notification) and I'm logged in (or, if using 2FA), I put in a passphrase or totp code
7. I accept any grants (email address, photo access, etc) as needed
8. I'm now logged in
   
   
   
   • The static app on generic-auth.com (or my custom auth site) caches that this site is allowed login
   
   

Secondary Login on Device

1. Behind the scenes the app loads a hidden iframe or postmessage to generic-auth.org
2. The app is either told to use generic-auth.org, or the peer auth the user supplied before
3. The app is given a pseudonymous pairwise identifier and short-expiry token without any interaction
4. The user is simply "logged in" with 0 interaction
5. The app silently renews the token (completely client-side, no server implementation), as needed
6. If necessary, a grants dialog appears asking for my email address, photo access, etc

Logout

1. When the user clicks "log out" in any web app (or app) that is passed via iframe or postmessage to the client-side and all private keys are deleted.
2. This means that client-side tokens cannot be renewed (as they were securely generated with client-side private keys)
3. Likewise an iframe or postmessage is opened for each of the list of sites which have been granted a token, causing their short-lived tokens to expire immediatley
4. The generic-auth.org server (or the peer auth server) are notified that they may remove "Chrome on Jon's Macbook Pro" (or whatever) and its public keys from the list of authenticated devices.

Security

• No cookies, only tokens
• Client-side token generation
• Short-lived tokens
• Optional (but default) sync of public tokens and of grants per app/site
• Only Facebook has a properly secure login that could feasibly be used on its own as-is
  
  
  
  • Twitter, Google, etc do not support PPIDs and are therefore insecure by default and cannot provide any information that could be used for encryption, etc, as all of the ids are shared among all apps/sites
  
  

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-22

Peer-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 .well-known instead of a follow-your-nose approach.

Email addresses are URLs too. If you assume an http:// scheme for an email address, fetching http://[email protected]/ provides the server with aaron as the username. Try it out:

curl -i http://[email protected]/

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 generic.co/user1 as their URL when they sign in. It's up to that service to make actually authenticating users as easy as possible, whether that's by emailing a one-time link, setting up a mobile app for push notifications, using a regular password, or whatever.

@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 indieauth.com because I never should have launched a service with the same name as the spec. That site is not a good representation of the concepts behind IndieAuth.

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.
But current flow cannot be called SSO or "OpenID Connect support" by any margin.
The whole point in Oauth2 (OpenID) is to store all users in ONE place.
I.e. currently gitea does not support any auth other than local.

@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.
The Oauth user is still able to use ssh and can login with his external provider.

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:

This is your first time signing in as `foouser` via `github.com`, but `foouser` does not exist here.

Would you like to

* Create a new account `foouser`?
* Link your `github.com` account with an existing account?

What I think would be best, in all cases, is to ignore the password altogether and simplify to a single flow across the board:

[begin if oauth]
You're signed in as `foouser` via `github.com` for the first time.

We need to confirm your email address just this once so that we have a recoverable link to your account in the future.
[end if oauth]

What's your email?

Thanks, go click the confirmation link.

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 git config credential.helper store (or by asking them to upload their ssh key right away).

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
I agree with you that OAuth login should transparently create an account and perfrom the log in as requested. However IMO setting a random password is a bad habit. Instead I prefer to disable "local" sign-in and http(s) cloning since the user doesn't know the password anyway.

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 believe a user who performs OAuth login is either a completely new user or has forgotten about his/her existing user at all.
So my suggestions would be to remind the OAuth user that he has to set a password to be able to use http(s) cloning perhaps with a horizontal banner below navigation, include a link that directs them to password setup and local account linking.

@grothesque @daviian I've started work on this (baby steps, highest value lowest cost first):
https://github.com/go-gitea/gitea/pull/5006

Progress. Here's a screencap and video of the requested changes:

https://youtu.be/jM8NL4IMM5Y

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.

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)

• https://github.com/go-gitea/gitea/pull/5033
• https://github.com/go-gitea/gitea/pull/5029
• https://github.com/go-gitea/gitea/pull/5006

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

My pull requests are against master, but I run them on my gitea as backport to v1.5.1 (includes https://github.com/go-gitea/gitea/pull/5006, https://github.com/go-gitea/gitea/pull/5029, https://github.com/go-gitea/gitea/pull/5033):

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 gitea in /opt/gitea/bin:

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.

As it currently stands, you cannot delete your account without sending a password-reset request to your backup email.
I guess this is a problem with all actions that gitea wants you to confirm with your own password. How do we solve this?

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.

So, it seems like #5033 and #5029 still aren't merged, and I think those two plus what's already been merged are what's needed to finish this? Or is there something that those PRs don't cover?

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: [email protected]

@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 Wanted

I'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

https://git.rootprojects.org/

Works! Steps I took:

1. I replaced the contents of my $GOPATH/src/code.gitea.io/gitea directory with the repository above and ran git checkout ux-master
2. Run the regular build command
3. Install the binary on my server
4. It first didn't start, apparently it needed to be able to change the config file to add a JWT_SECRET in the oauth2 section, so I gave it write permissions (chmod 0600) and it worked.
5. Then my reverse proxy couldn't reach it: I configured 0.0.0.0 in gitea as the listening address but it was listening on [::] only. The latest release did not have this issue. As fix, I hardcoded the v4 address of the server as listening address and that worked.
6. Added an oauth2 auth source in https://$gitea/admin/auths/new, for which I needed to register an application on GitHub
7. Opened a private browser window and went to https://$gitea/user/oauth2/GitHub?redirect_to=. This redirected to GitHub, I logged in, clicked Authorize, and got a 500 internal server error[1]. Figuring that the site did not create a session when redirecting, I went to the homepage, then clicked sign in and continued the flow from there, and that worked.

[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:

• Not sure if it's a bug that this error[1] is possible? We might consider it to be a very exceptional case and not bother with fixing it, depending on the complexity of a fix.
• Not sure if it's a regression that it now listens on v6-only?

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 <username>@nowhere.local. Do we want to be able to configure the email address to be an optional field?

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.

500

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

IPv6

I didn't make in changes in that area. master represents v1.9-dev. I listen on localhost and have my reverse proxy connect to that, so I haven't experienced this issue.

Email Address

There 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, _gothic_session, with an expiration time of right now. The browser, of course, does not return it. The second time around, it also sets that cookie, but it does return it.

The error I see in the logs appears in two places in the source code: in vendor/github.com/markbates/goth/gothic/gothic.go lines 302 and 311. I modified both and observed that the error is the former, on line 302, in the function GetFromSession.

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:

• disable login using a user that doesn't come from an external authentication source
• fetch the email from openid (no need to ask the user for their email, openid gives it to you)
• don't ask for password (again, that's the point of openid)
• the user stored is just a reference (sub field) to the openid user with the email and name cached in db to be able to send him notifications

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