I'm trying to add some business logic to my REST API that requires cross user interaction. We have separated our resource server and authentication server.
What would be the proper approach to interact across users by for example searching for names, emails of other users ++, if inside the same "group" at the resource server. The reason why this is problematic as of now, is because no user information is (or should?) be stored in the resource server. Only the identifier provided by the OpenID Connect provider.
Now there is of course no problem getting the authenticated (my own) users information through the userinfo endpoint. However, there is nothing to tell me about the other users (not me). Also it would be unwise I believe to make a "get userinfo by id" endpoint on the authentication server.
What is the best way to handle such a problem? Is there a set of best practice rules layed out for this? Do I actually need to save each users information twice? Once in the authentication server and once on the resource server? If so, what is the correct way in order to sync these two user models, as they are completely decoupled besides the unique identifier.
There are two cases.
The Resource Server and Authorization Server both are connected to one data source which is containing all the user information.
The Resource Server and Authorization Server are connected to two different data sources, the data source which is connected to Authorization Server is containing the user information.
It depends on your application requirements that which case you use. But the scenario for cross-user interaction will be different for both the cases.
As you mentioned it clearly shows that your app has the requirement for viewing other users information up to some extent (like we see on facebook).
If you go with case 1: You can expose all users information to the logged in user (of course you"ll expose the user profiles to the logged in user, not the account information) and the logged in user will only need his/her own credentials for logging in and viewing other users (its just like viewing books in a library management system)
on the other hand
If you go with case 2: You can have an another (say user rest API) rest API that would be connected to your data source which is containing your users and it will expose users to your resource server. This API will be protected by your authorization server.
Then your resource server will also be the client of your authorization server via client_credential flow. The user rest API will only expose users to your resource server no one outside the resource server will be able to get users from the user rest API.
Your resource server will get the access token for your user rest API and using that access token it will get the required user information. Your user rest API will expose all the user endpoints to your resource server (for example "/AllUsers", "/SearchUser" etc.).
MY RECOMMENDATIONS:
If you don't have any specific requirement to keep the database of Resource Server and Authorization Server separate, I would suggest you go with case 1. This is how I would like to go it's pretty simple and straightforward approach.
But, If you have some specific requirement to keep the database of Resource Server and Authorization Server separate then there is a solution for you in case 2.