Multiple Authentication Mechanism with Authorization

[sskhokhar]

Hi all,
First sorry to post here, I have asked on slack but no one answered.
I need help in designing authentication and authorization mechanism in LB4
I have following entities:
1- Administrator (login with email and password)
2- Buyer (login with phone number only - verified by OTP)
3- Seller (login with phone number only - verified by OTP)
4- Support Assistant (login with phone and Password)

What would be the best way to do that? I cant create a single model for Users because every user entity has different relations with different models.

[jannyHou]

Hi @sskhokhar no worries at all :) having a public discussion about comprehensive user scenario would also benefit community.

• For the login part:

I think different login approaches can be handled by multiple login endpoints, an example would be the passport-login.
It allows login with local user/fb/google/twitter. (You'd better run that example to see how it works)
See the login ui and login controller

Multiple users doesn't matter IMO. When you decode the user information from e.g. a token, the authentication system passes a very flexible user profile object(it supports any users) to the authorization system to make the access decisions.

• For handling different roles:

Example of access control would be a good reference. That repository only has one user model specified with different roles, but in your case, you can treat different users as different roles. Remember the authorization system only collects user information, e.g. is it an admin, or buyer, or seller, it doesn't care how the abstractions of those information are created.

[sskhokhar]

@jannyHou Thank you for reply. I appreciate it

I have tried to use the authentication component, but the problem is token service only takes email, password and security id to generate token i.e "UserProfile" interface.
What if i want to pass in extra user profile as an identification whether the current user is Admin, Seller, Buyer or Support.

To bypass this barricade. I was thinking to do following:
User Model with props:
1- phone
2- email
3- password
4- type (whether the instance is of Admin, Seller etc)

UserService:
a function to check creds via "type" and generates the token using different types of creds

UserController:
A single login controller which accepts creds as well as "type" to specify the user trying to login

What do you say about this?

[sskhokhar]

@jannyHou This is the architecture i came up with. Let me know if you’re confused
In this diagram, its stated that all entities has to call single Login endpoint controller. This controller will decide further actions and call specific services

[jannyHou]

@sskhokhar UserProfile allows arbitrary properties, see
https://github.com/strongloop/loopback-next/blob/e72e12cb074044b97c65ab416605ed073fca6d19/packages/security/src/types.ts#L37
It extends Principal which can have any properties.

[argupta23]

@sskhokhar

Did you ever resolve the issue?

@jannyHou

How would this work in a multi-tenant case where there is a a single common database?