We have two applications, each of them separated with its own backend and frontend.

The first application is the user-facing one. They register on the site and as soon as they want to execute a critical action they should be redirected to the frontend of the second application that will ask for the users personal data.

When implementing this, we proposed the following:

  1. On the redirect action, app1 requests app2 to "initiate a flow". This returns a token (probably jwt?).
  2. Now, when this redirect happens, where can I locate the jwt? I mean, if the frontend is a client-side app, wouldnt I mess it up by passing the jwt via query param? Or can I have a sort of shared cookie between different domains?

My suspicious is that I am trying to reinvent the wheel, at first I thought that using something like OAuth would work out, but the flow starts to complicate as soon as a new use case comes by and is the following:

  1. User registers in app1
  2. Wants to execute a critical action on app1, is redirected to app2
  3. User authenticates with app2
  4. Fills its information, and also "generates" new users
  5. These users now have to authenticate in app2 and load their information
  • You can run both apps on the same domain, just different path and use cookie auth, so they keep the authentication between the applications
    – Mr Zach
    Mar 17, 2022 at 9:43
  • But wouldny each of these apps have their own userbase? If I want to give a seamless experience, would app2 be able to read cookies from app1 so it knows how app1 user is related to app2?
    – Matias
    Mar 17, 2022 at 22:17

1 Answer 1


Oauth flow is the right approach here. Your first application is the identity provider and the second up is the resource.

You could do a lightweight oauth flow - these are sometimes implemented by hands due to simplicity (but I still prefer to pick a library at is incredibly simple to mis an edge case).

For the overall high-level flow:

  1. When your user is logged in into the app 1, they have a session. This session is for app 1 only (e.g. cookie is scoped for the app 1).
  2. The customer arrives to app 2 and the app checks for app 2 session; it is important for every app to have their own session.
  3. Since app 2 has no session, it redirects the customer to the app 1 endpoint - something like app1/idp
  4. App 1 knows the user - the app 1 session is on - so it generates a code and redirects the user back to app2/redeem?code=123
  5. App 2 calls App1 from back end to redeem the code - something like app1/redeem... - and app1 return whatever needed about the user
  6. App 2 creates its own session

These are basic steps of a federated login.

An interesting feature is that customers don't have to always start with app1 to get to app2 - if at step 4 the app1 has no session, it can ask the customer to login right there.

As I said above, this is the way I would go - use a usual web standard. Saying that, I have seen "simpler" approaches, where a suer would be redirected to a target app with an encrypted token with all info - and the token would have expiration date and other stuff to beat replay attacks - the problem is that the implementor has to know all these types of attacks.

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.