Establish browser session using token/cookie from REST API

Question

I am trying to build a scenario where a front-end application (application A) calls REST APIs of another application (application B) to authenticate a user. Application B generates a tokenId for the user and sends it back in the REST API response once the user is authenticated

Application A now wants to utilize this tokenId to also establish a browser session of the same user with application B, so that later it should be able to redirect the user to application B as and when required (without prompting for username and password again because user is already authenticated over REST)

Application B expects the tokenId to be part of a header in order to identify the authenticated user and trust it is authenticated.

Now there are two questions:

1. Is it possible to do above technically? If yes, how can we pass the tokenID from response body of REST API to browser at the time of redirection to establish session (I am thinking of something like creating a hidden form and doing a POST but not sure how tokenId can be included in the header with this setup)
2. Is there any security concern in this type of setup/flow?

Kindly need guidance on above, suggestions and ideas are also welcome!

Answer 1

I am thinking of something like creating a hidden form and doing a POST but not sure how tokenId can be included in the header with this setup

AFAIK this cannot be done. You cannot set a header in a normal form POST. The only way to set headers in a form post is in an AJAX call.

Here is how I'd do it.

Create an API service in application B that accepts the tokenID and returns the URL of the page in application B that you want to redirect to. You can include this in the Location header in the response. I'd append a query-string param to this URL like this.

https://appB.com/redirect/to/this/page?key=<one-time or time-bound JWT>

This JWT can include some publicly identifiable information in its sub claim like ID or email address of the user. You can make it either one-time or time-bound by including a timestamp and only considering it valid if it is used within 5 seconds or something. Restricting this JWT with the one-time or time-bound constraints should be enough but here are some more security best practices you can follow.

If you don't want to use a JWT, you can simply just encrypt the publicly-identifiable information and timestamp with a private key that is known only to application A and B.

Then in application A, this response shall be received and the redirect shall happen using the URL in the Location header.

The page in application B to which the redirect happens will read this JWT and verify it and create a session for the user. In case you used your own private-key encryption, then you'll decrypt using the same private key.