RocketChat / RocketChat/Rocket.Chat

Custom Oauth login with provider access Token

Open
#21,156 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
TypeScript
Stars
46.1k
Forks
13.9k
Avg merge
3d 3h
Merged PRs (30d)
130

Description

Description:

User created with login and password cannot login via RC API unless he logs in with RC web app first.
I belive it's a bug, however it may be my mistake somewhere in the process.

Steps to reproduce:
  1. I have working instance of RC with a bunch of users created with login and password via RC API.
  2. I add Custom OAuth provider (it's my own provider, so there is the first place where my own mistake is possible)
  3. I want users logging into my app to log into RC REST API using my own access token. So i make login request sending all required data like described here #14108
  4. RC seds request back to my identity endpoint to which i respond with user identity.
  5. I recieve 403 response from RC with 'Username already exists'. However it is true, I would like to log in on that user, it seems that RC is trying to create new user with my data instead of loging me to existing one.

Some more info.
My OAuth provider has the option to merge users set to true.
My identity response contains email, username, name and my own id.
I checked users data and it is the same in RC as in my response. If I change something, like username, then error changes to Email already exists, thats why i suspect that RC is trying to create new user instead of merging one.
If i send not existing (in RC) user data, the user is created and everything works fine.

Important point, if i go to RC web app (Show button on Login Page = true), and login with my oauth provider from there, login is successful.
Furthermore after successful login from RC web app, the scenario starts working as intended.

I checked users collection in RC db and after logging in from RC web there is my oauth provider in 'services' map in user object. If i add this data manually to a user, the scenario also works correctly.

So seems to me like there is a part missing in API login request that is present in RC App that adds service to user when he attempts to login via this service for the first time. I don't know if this is deliberate behavior, to always force user to login in app first of simply a bug.
Is there some method i should call first to register my OAuth provider for users first?

Can maybe anyone suggest some workaround this issue? Currently im considering just accessing RC db directly and writing my service for exsisting users, but thats not really a solution that i like too much.

Expected behavior:
Actual behavior:
Server Setup Information:
  • Version of Rocket.Chat Server: 2.4.6
  • Operating System:
  • Deployment Method: docker
  • Number of Running Instances:
  • DB Replicaset Oplog:
  • NodeJS Version:
  • MongoDB Version:
Client Setup Information
  • Desktop App or Browser Version:
  • Operating System: centos
Additional context
Relevant logs:

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by comparing the Rocket.Chat REST API OAuth login flow with the web-app OAuth flow described here, using issue #14108 and the provider identity response as entry points. Check how the existing user's OAuth data is handled in the services map; done means an existing password-created user can authenticate through the provider without first using the web app or receiving duplicate-user errors.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
api, authentication
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.