Rocket.chat: Oauth2 (auth0) users can't log in

[aforsythe]

Description:

Users logging in for the 2nd time via OAuth2 receive “email has already been used” error.

I’m using Auth0 to manage users. Users are able to login without trouble the first time. When trying to log in the second time they receive an message that “email has already been used” and are prompted to change their password. This doesn’t make sense as passwords are mostly managed through social accounts (e.g. github, google, etc.)
Server Setup Information

Steps to reproduce:

1. User has verified account on other platforms using the Auth0 application
2. User tires to log in using the credentials from above via Auth0 universal login experience (classic)

Expected behavior:

User should be logged in with all user metadata sync'd from Auth0 database

Actual behavior:

User is presented with "this email has already been used and has not been verified. Please change your password. Type new password." dialog.

User shows up in user list in rocket.chat users section. Listed as verified. Listed as online.

Server Setup Information:

Version of Rocket.Chat Server: 3.4.2
Operating System: Linux
Deployment Method: SNAP Tracks
Number of Running Instances: 1
DB Replicaset Oplog: ?
NodeJS Version: v12.16.1
MongoDB Version: 3.6.14
Proxy: Caddy
Firewalls involved: No

Client Setup Information

• Desktop App or Browser Version: All apps and browser
• Operating System: All OSes

Additional context

Followed instructions located here:
https://github.com/RocketChat/Rocket.Chat/issues/8492
and here
https://forums.rocket.chat/t/anyone-auth0-sso-experience/2060

Relevant logs:

I20200727-20:06:41.422(0) server.js:204 CustomOAuth ➔ debug Identity response {   "email": "[email protected]",   "family_name": "XXXX",   "given_name": "Carol",   "locale": "en",   "name": "Carol XXXX",   "nickname": "carol.XXXX",   "picture": "https://lh3.googleusercontent.com/a-/AOh14GiH5VSBWXT3crhSx7qWiu4ogk_y_E4rlp-y6MVCsw",   "country": "United States",   "clientID": "rfV0x1ICdNbMe5vRBpyPANOm5ycUdDdz",   "created_at": "2020-04-21T18:43:33.248Z",   "email_verified": true,   "identities": [     {       "provider": "google-oauth2",       "user_id": "110878763390166151103",       "connection": "google-oauth2",       "isSocial": true     }   ],   "updated_at": "2020-07-27T20:06:40.304Z",   "user_id": "google-oauth2|110878763390166151103",   "sub": "google-oauth2|110878763390166151103" } 

I20200727-20:06:43.133(0) server.js:204 API ➔ debug POST: /api/v1/method.callAnon/login 

I20200727-20:06:43.168(0) server.js:204 Meteor ➔ method joinDefaultChannels -> userId: m76CX5yRhqtDC8Yij, arguments: [null] I20200727-20:06:43.302(0) server.js:204 Integrations ➔ Outgoing WebHook.debug Execute Trigger: userCreated I20200727-20:06:43.304(0) server.js:204 Integrations ➔ Outgoing WebHook.debug Got the event arguments for the event: userCreated {   event: 'userCreated',   user: {     _id: 'm76CX5yRhqtDC8Yij',     createdAt: 2020-07-27T20:06:43.146Z,     services: { auth0: [Object] },     type: 'user',     status: 'offline',     active: true,     name: 'Carol XXXX',     emails: [ [Object] ],     username: 'carol.XXXX',     _updatedAt: 2020-07-27T20:06:43.147Z   } } 

I20200727-20:06:43.306(0) server.js:204 Integrations ➔ Outgoing WebHook.debug Starting search for triggers for the room: __any I20200727-20:06:43.308(0) server.js:204 Integrations ➔ Outgoing WebHook.debug Found 0 to iterate over and see if the match the event. I20200727-20:06:43.366(0) server.js:204 Meteor ➔ publish null -> userId: null, arguments: [] 

I20200727-20:06:43.376(0) server.js:204 API ➔ debug POST: /api/v1/method.callAnon/login I20200727-20:06:43.397(0) Failed login detected - Username[unknown] ClientAddress[72.134.165.246] ForwardedFor[72.134.165.246] XRealIp[72.134.165.246] UserAgent[Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.116 Safari/537.36]

 I20200727-20:06:43.402(0) server.js:204 API ➔ debug Success {   statusCode: 200,   body: {     message: '{"msg":"result","id":"1","error":{"isClientSafe":true,"error":145546287,"reason":"No matching login attempt found","message":"No matching login attempt found [145546287]","errorType":"Meteor.Error"}}',     success: true   } } 

[y377]

Two RC are used to test OAuth login, but an error is reported

me too
If a user only registers server a, uses mailbox [email protected], and then OAuth logs in to server B, the problem is that the two server administrator accounts use the same mailbox, the above error will appear, and the administrator account cannot log in again. This is a bug

[daniel-illi]

I see the same bug with a different oauth2 provider (custom oauth).

same bug: #18255, #17307

[aforsythe]

Is there any reaction to this? This is a show stopper for us. Users simply can't login.

[andyedinborough]

I've been manually updating the user records in Mongo to mitigate this. 😒

[tofr]

Thank you @aforsythe. This is a big problem. We have reproduced this behavior repeatedly, as we doubly- and triply-checked to make sure we had not configured something incorrectly. It is exactly as described above. (Except that we are using OAuth2 with google.)

Seems OAuth2 should not be advertised as something RC can do, when it in fact cannot. Other features are flagged as "beta" in the settings panel. Perhaps this one should be as well?

Any idea on timeline of resolution?

[aforsythe]

@tofr This is exceedingly frustrating. The rocketchat team even gave specific instructions on how to set this up with my provider (auth0) here https://forums.rocket.chat/t/anyone-auth0-sso-experience/2060/8

I'm wondering if SAML might work better but frankly I don't know where to start to set that up.

[adraut]

Workaround

db.users.update(
  {
      _id: '{Affected_User_Id_Or_Omit_For_All}',
    },
    {
      $set: {
        requirePasswordChange: false
      }
    }
);

[aforsythe]

@adraut Sorry but how does one go about implementing this workaround?

[pierre-lehnen-rc]

Is the error still present on the latest version of Rocket.Chat? I've tested it with multiple OAuths (Including Auth0) but I was unable to replicate it.

[aforsythe]

@pierre-lehnen-rc I'm on 3.6.2 because that's what appears to be in the snap channel.. Issue still exists in 3.6.2.

User attempts to login 1st time, gets thrown back to login screen with no message, attempts to login 2nd time and recieves "This email has already been used and has not been verified. Please change your password. Type your new password"

[aforsythe]

@pierre-lehnen-rc when can we expect 3.7 to be in the snap channel so I can check that?

[andyedinborough]

I was just able to reproduce this on version 3.7.1.

[aforsythe]

@pierre-lehnen-rc Any updates? Seems like others can reproduce on the latest version.

[zim32]

The same thing. Same error message with my custom openid provider. I can see that rocket chat does not take into account email_verified field from USERINFO openid endpoint. But it should. And when creating user with email_verified eq TRUE it should not ask user to verify email again.

[zim32]

I think I found solution. You need to go to /admin/Accounts settings, then Registration tab and check Verify Email for External Accounts. Then new users will be created with email verified set to true and error is gone

I thinks this is bug, because if checkbox is checked (active), email verified flag must be false, and otherwise true. It must be fixed somewhere here https://github.com/RocketChat/Rocket.Chat/blob/develop/app/authentication/server/startup/index.js#L180

[aforsythe]

This work around sorta works ... on the first login attempt the user is kicked back to the login window as they always have been. On the second, and subsequent attempts they can get in. Obviously this is still a bug.

[sheuschkel]

Any news on this?
Have this bug with an custom oauth provider and gitlab as oauth provider.
Rocketchat Version is 3.7.1.

Actually i use the workaround from https://github.com/RocketChat/Rocket.Chat/issues/18391#issuecomment-703113449

[andyedinborough]

We're on 3.9.1, and still seeing this issue. Our user records are marked as verified, and we still see this. I finally setup a cron job to run this script every minute: mongo rocketchat --eval 'db.users.updateMany({ requirePasswordChange: true, requirePasswordChangeReason: { $exists: true } }, {$set: { requirePasswordChange: false}, $unset: { requirePasswordChangeReason: 1 } })'.

[MJPGPleasant]

This has become a HUGE issue for our rollout. We are working around it by logging in as Admin and toggling the "Verify email" fag for the user affected. However if this continues to happen we may be forced to roll back our implementation.

Custom OAuth using AzureAD, RC 3.9.1

[relikd]

I've had this issue too. But I seem to have fixed it with this configuration:
Go to Administration > Users > Registration, disable "require name for signup" and "require password verify" (is handled by the oauth anyway). Make sure that "verify external email" is set to on, as otherwise the email addressed won't be marked as verified upon registration. Sometimes I got a "enter your verification code" dialog. So I've also disabled auto opt-in for two factor email verification just in case. But I am not sure if this is realated.

[relikd]

I have another issue with nextcloud OAuth login. Actually two issues. First, if I use the built-in nextcloud OAuth config, that login button is not shown in the RC iOS app. So I've set up a custom OAuth handler which is doing fine. Except, every successful login is logged as a failed login attempt in nextcloud. Resulting in the brute-force app to block all connections to RC and making the OAuth login impossible. An "udefined" error is shown in the top right corner and the console shows "websocket connection timeout".
Can this be related to the way RC implements OAuth? Idk. maybe not completing the handshake or similar? I ask because using the same nextcloud instance on a Wekan OAuth login form works just fine.

Also, see my comment on the related brute-force nextcloud app:
https://github.com/nextcloud/bruteforcesettings/issues/223#issuecomment-750880392

[Gummikavalier]

We got this issue with brand new RC Oauth-endpoint-config. Old endpoints don't seem to be affected.