I'm trying to build OAUTH2 provider (like discord/google) where user can create an "application" that has client_id, and client_secret. While researching I found OAUTH2 is best for this kind of thing.

Now part that is confusing is how does main login page work?

Do I have my own /login route page with POST /login as well to handle my own users, and this way I will have 2 tables:

• MyOwnSession - this will keep my own platform issued access tokens with full right over API
• OAuthSession - tokens issued to third-party application (keeping track of client_id, and scope they have) (issued by api/oauth2/token!!)

Then my protected routes like /api/user will both check Authorization: Bearer <access_code> and check both tables to see if this is valid access token (bit redundant?)

So I'm pretty sure on how I'm going to implement OAuth2 flow for clients (third-party), but I'm very confused on how does main platform (OAUTH2 app that will give users right to change password, and create new clients/applications) handle session.

Any tips? thanks!

Edit:

Ok, so from what I found is that there is no real definition on this kind of thing..

For example Discord has POST /login where they send username password, and handle all other 2FA.

And handle OAUTH2 separately.

So in short when building your own OAUTH2 server/provider (eg. you want to be Google accounts/Discord) to handle your own login, you can do it any way you wish, and then oauth2 routes are only to be used by other clients (third-party?)

Now I'm doing react-frontend for my own project, and I also want to have access_token, and refresh_token for more security! But I don't think it's smart to share same table with OAUTH2-tokens as my tokes will have full permissions, and oauth2 tokens will only be scoped to request of other application (clients third-party).

What would be the best way to check if access-token is valid in my backend? I'm guessing check both tables if access_token exists? or try to fit them both in single table (or use UNION to get both at same time)

CodePudding user response：

MyOwnSession - this will keep my own platform issued access tokens with full right over API

OAuthSession - tokens issued to third-party application (keeping track of client_id, and scope they have) (issued by api/oauth2/token!!)

Do you really need separate tokens? Your app will act as OAuth2 provider and can issue tokens to your app and third parties clients with different client ids. You can control the access rights as per client ids.

CodePudding user response：

As previously mentioned in my edits it seems that two table strategy is the best (following what discord did)

Now there is no need to use unions or two selects we can just have multiple token_type, eg: Discord Has:

• Bot
• User
• Bearer

Based on token type we know how to validate access_token provided.

OAuth2 should only worry about giving access to third party, and our own login should be structured in the way it best suits our application.

Bearer could be the type that OAuth2 issued, and User could be the token when user actually signs in into our platform (not third-party)

Pretty sure this is the only answer.