Google OAuth SSO Creates users that already exist

I configured OAuth with Google’s OAuth services, using the template from this manual page.
After configuring the server I visited my user page, expecting to see a “link your account with X service”, but nothing similar showed up.
Then I thought “Ok, maybe if I try to log in with the Single-Sign-On button on the login page it will authenticate using my google account and then ask me to (authenticate and) link it to an account on the server”, but nope, a new account got created on the server (even though I disabled account creation to the public) with the “Email contact” field set to the username of my google account, and with numbers as the username.

I think this OAuth implementation goes against the usual way this gets implemented, which is An alternative way to let a user authenticate to the server using an intermediate, known, common service and replaces it with basically Easier LDAP. Unfortunately this is what I have to say about my experience with this feature so far, I hope it gets better in the future. Thanks for reading.

1 Like

@daniel.pan I think that the create account over blocked public registration is a bug.

+1 for connect existing account with OAuth account. I implemented it in PHP Web Apps and think it’s no too much hard if you have good library. I know python a little bit (Raspberry Pi scripts) but no Django framework so I can’t prepare PR for you.

This is a designed behaviour to not let SSO to use existing user’s account.

For Google OAuth, if you really want to let users login into their existing account (identified by Email), you can change the config file like this:

OAUTH_ATTRIBUTE_MAP = {
“email”: (True, “email”),
“name”: (False, “name”)
}

This will use the email field in Google’s OAuth as the email field in Seafile.

Yes that’s good idea. But It’s shouln’t overwrite public registrations settings. And there should be ability to pair with existing user. I mean in user profile by user.

For some system, like Github, email is not the unique identifier for an user, but id is in most cases, so we use id as settings example in our manual.

As Seafile uses email to identify an unique user account for now, so we combine id and OAUTH_PROVIDER_DOMAIN, which is google.com in your case, to an email format string and then create this account if not exist.

If you want to use email info from Google, just change the setting as followings:

OAUTH_ATTRIBUTE_MAP = {
    "email": (True, "email"),
    "name": (False, "name"),
}

This will be fixed in the next version.

1 Like

Given the circumstances for the CE, I think that linking an existing server account with an OAuth provider is a much better way of implementing SSO, since the user CAN use the feature, but is not locked into/out of it, and by implementing the linking process as an explicit action that the user needs to perform in order to use the feature, you get rid of unintended account mappings by the server maintainers.

Hi Daniel,

In the case of Shibboleth Login, SSO is using user’s account when eppn=email or when email is set for login in Seafile.
Then, i don’t understand why you choosed a different option for OAuth.
I’m just curious.
Regards,
Gautier

The lesson we learned from the past is that users will change their email address.

So when design the OAuth, we think it is better to use the ID from the OAuth server as user’s ID (the email field) in Seafile. Another reason is that users can change their email address in GitHub very easily. So using the email as the user’s ID is not safe.

1 Like

This is against OAuth. Either one wants to have SSO or not.

You mean as a single point of entry to an account?

Yes! OAuth was designed to use one account for different services without having to send the credentials to each party and without having to memorize different credentials for each service.

That’s why I said “Given the circumstances for the CE”, as this feature was added recently and there are users that’d like to take advantage of this feature without having to recreate their accounts just for the sake of having SSO. This all-in or all-out approach is imho not practical, to the point where it could become useless in most circumstances. As the common use case for the CE of seafile is home cloud or office use, where new users are rarely added and accounts last as long as the server does, as I said, most users won’t bother to recreate their accounts just for the convenience of having SSO. This turns down a feature most commonly used due to its convenience because of how inconvenient it is to set up for existing users.

Hi,

Please also consider tths Shibboeth mecanism, wich is quite the same as OAuth one.
If you plan to change Oauth rules, please do the same for Shibboleth. (But i think it is already the case, no ?)

As you know, the Persistent ID feature added into Seafile for some Shibboleth or LDAP issues regarding the email unpersistent attribute may be generalized to all SSO.

To let you know @daniel.pan, some services providers as ORCID Identitiy provider gives the ability to create threee types of accounts :

  • local ORCID
  • Shibbioleth
  • OAuth.
    Orcid gives the ability for a user to reconcile all its identities. When signed up (.domain.com for local Orcid account), you can sen send an email to any of the other identity (.gmail , *.university.ac, etc.) and reconcile all of them to a single account, with preffered contact email.

It is very useful. You can test the feature on Orcid event if you dont’ plan to publish articles.

Regards,

Gautier