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:
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)
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:
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.