The following scenario:
You have sensitive and protected user infos (name, mail adress, telephone number, adress) securily saved in an authorization server (e.g. IdentityServer4).
You have an API loading data from a second database storing your own data (not the sensitive user data). This data is somehow linked to users (lets say we store documents and the document A belongs to the user with auth-id "XYZ").
The problem:
Now a single page application gets a list of documents and wants to display the name and email-address of the user that owns the document.
So far I understood the OpenID Connect UserInfo endpoint to ONLY return the user info for the current logged in user but not other users. So there is the need to get the infos for the other users somewhere else.
Solution 1: Copy the user info into the second database. That would leak sensitive data out of the secured autorization server, introduce the need to keep the data in sync (if changed on the auth server) which introduces a connection between the auth server to the second db or the auth server to an API endpoint.
Solution 2: Let the API access the auth DB and grab the data from there. Possible but introduces the DB connection to the authorization DB what is (in my personal opinion not good).
Solution 3: Introduce an endpoint (like the UserInfo endpoint) on the authorization server that lets the single page application request the user info by auth id. Seems most practicable but seems not to be specified?
Is there an official specified/recommended way to solve that? Maybe a specification to use the UserInfo endpoint for that which I have missed so far?
simply my.domain.com/userinfo/XYZ that returns the infos for the user with auth-id XYZ???
Following is extracted from the OpenID Connect specification's user info endpoint section,
The UserInfo Endpoint is an OAuth 2.0 Protected Resource that returns Claims about the authenticated End-User.
As highlighted section explains, it expose information about originally authenticated user. There is no way to obtain information about other users unless you have an OAuth 2.0 access token authenticated for them.
Also, embedding an endpoint to authorization server is not recommended. It brings maintenance burden as well as privacy issues. Also, this will prevent you from alter the authorization server (ex:- Your sell this app and that customer use Azure AD). So don't do such non-standard ways.
Proposed solution is to obtain the user name and email at the time user create this document. At the time of creating, I believe application have an access token authenticated to content creating user. So you can get claims from user-info endpoint and store them along with document. And when another user get the document, you can reveal user name and optionally email. May be you never reveal email but give the ability to mail the owner which would be handled at back-end.