Auth flow between two services

Question

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

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.