Please see the below diagram. 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?

1 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.

  • 1
    The question implies significantly more complexity than you've described here. A good answer would touch on multiple OAuth grant types and provide for a way for the two apps to communicate with each other without giving users access to apps for which they aren't authorized. Commented Jan 25, 2019 at 6:01
  • Thanks for your answer. It has cleared up a couple of things, but as @RibaldEddie states the authorisation between app1 and app2 isn’t clear in this scenario. UserB makes a call in App1/two which app1 makes use of an api call to App2/Six would be a good example. Perhaps one idea would be to forward on the JWT with the request so App2 could authorise that UserB is allowed to call that function, however that falls down in a situation where we would never want User B to directly call that API function as it’s purpose is to provide information to App1 Commented Jan 25, 2019 at 7:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.