Multiple app authentication, universal user login, best practice

Question

Please see the below diagram.

There are two apps that each have a different set of functions, User A is a user of App1 and User B is a user of App2. They should not be able to log in directly to the other app.

App1 and App2 both call each other to share some of their functions so although a user can not log in to the other system, they should have access so the call can be made to a specific function from the other app.

User A can access the green functions and User B can access the red functions.

There is actually a third user that is an admin and should be allowed to log into both apps and access an enhanced level of functions.

Ideally the login/authentication system should be standalone and the app's can call it to check a users access to functions.

Is there a standard way of achieving this, like with Oauth2 or JWT?

Is it unrealistic to think that each time a function is called the users level is checked by the external auth service?

Answer 1

OAuth2 is a means of identifying a user, or a process that is acting on behalf of the user. The identity server (OpenID, Facebook login, Google login, etc.) has a token that positively identifies the user, and that token is used in any exchanges.

What you are talking about is the means of authorizing a user you have identified. You can have the same identity server across your applications, and provide a new token which embeds the roles and claims that are specific to your infrastructure.

In the latter scenario, you can have your own user management service use an external ID server to identify a user, but your user management service issues its own token that is used with all calls by and for that user. JWT would be a good candidate for this scenario.

The process would go like this:

• User clicks a button to authenticate against the ID service (OpenID, Facebook, etc.)
• The callback to your user management service accepts the ID service's token
  • user management service looks up all claims/roles for your suite of applications
  • user management service issues an application specific JWT token with that information embedded
• User interface includes that token using the HTTP header "Authentication" to pass that JWT token along with all requests to your application
• Your application validates the JWT token (to make sure it isn't forged) and simply trusts the claims/roles included.

Since JWT tokens can (and should) be signed, you simply need to validate that they are signed with the algorithm and key that your application has agreed to. No further calls to the user management server are required after that.