CODEWITHSUNDEEP
oauth-2.0api-design
Razvan Mihalache
Razvan Mihalache

Reputation: 31

How to handle user registration in OAuth Server when it is separated from the Resource Server?

I am working on an application in which users with elevated roles (administrators) can create other users (with lower roles). I'm using PHP (Slim framework) and MySQL.

So far i have a Resource Server which can be accessed through a REST API with access tokens obtained from the OAuth Server using the Password Grant. The two servers have separate databases. There is also a Web Server which provides a dashboard where administrators log in and create new users by setting their username, password and other generic information.

Considering the fact that both the Resource Server and the OAuth Server have to store user data in their respective db tables, would it be ok if the Resource Server, upon a new user request, stores the generic user info in it's "users" table AND sends a request with the user credentials to the OAuth Server which will add a new entry in it's "oauth_users" table ? If not, what would be the best and secure way to achieve this functionality ?

Thank you in advance!

Upvotes: 3

Views: 1331

Answers (1)

Antonio Saco
Antonio Saco

Reputation: 1650

This approach works for us.

On the Auth Server db side you have to store only: user id, redirect url's and authorized service level (scopes) configured; the access tokens granted; and other authorization required data (roles in your case).

The Login Server db, stores: user id, password and other authentication related data.

The User resource service (commonly a RESTFul API) should store: user id and other personal data.

Upon a new user request of a secured resource data (some scope is needed here), redirects to the Login Server, with this successful authentication, redirects to the Auth Server to grant permissions using that scope, generate an access token and redirect to the secured resource with an access token, the resource server validates the token and the scope (some implementations also make another call to the Auth Server to validate this using JWT) to finally allow the initial user request.

In general, I personally use the DRY principle with this kind of architecture.

Cheers!

Upvotes: 2

Related Questions