Token Passing Between Backends The Service Different Clients

My team is developing a system that involves multiple front end applications which each retrieve data from its own back end service. In certain instances, a back end service for one of the apps needs to call an endpoint in one of the other back end services. Basically in one app, you can create and customize forms, and another app can render and let users complete a form. So the app where the user fills out the form makes a request to its backend, which forwards the request to the form configuration app’s backend to get the form details to be rendered.

In development, we’ve been using one Client ID for all the applications, so when you’re logged into one, you’re logged into all of them. We’ve been able to get by just forwarding the bearer token in the authorization header of our requests, and we’ve been good to go. These are all Angular apps, so running locally, having an initiate login URI of localhost:4200/implicit/callback has been fine. Now, as we prepare to promote the system to a test environment, we realize it’s not going to work, because we will have multiple URIs initiating logins, so we can’t use the same application across the board. But if we create separate clients for the apps, it doesn’t seem like our token passing strategy is going to work anymore.

We figured when the time came we could just “set up SSO”, but from my reading of the documentation, Okta’s take on SSO is such that you can launch various apps from a landing page without having to re-enter credentials, but not such that when you are logged into one application, you are magically logged into all of them.

I’ve been searching around the web for solutions, but coming up empty-handed. Is there a preferred way for handling this type of microservices-esque architecture, where backend services need to talk to each other, though they each also service their own front-ends? I’ve seen some articles that mention server-to-server credential flows, but it’s important for us to retain the user context. It’s not simply the server requesting the data, we still want it to be the user.

I appreciate any insights. Thanks!


  • all of your applications (A, B, C) are under the same authorization server
  • you may create scopes for each of your apps on authZ server “sA”, “sB”, “sC”
  • and user “a” is assigned to all 3 applications (assuming he’ll be trying to reach/authorize operations on user’s behalf on each of them)

then getting an access token from any application with required scopes (sA, sB, sC), will allow you to pass that token to respective applications, which will validate if a proper scope is in the token