Passing authentication token in header while redirecting to a new SPA page

Question

Assume these:

       A -----------------------> B
(Sender website)          (Angular website)

We implemented a normal Angular SPA (B) that its index.html and other resources are simply hosted in IIS and there is a simple rewrite rule for handling the routes in Angular. Users in Angular need to login and they get a JWT token and it is storing in browser storage.

There is a website (A) that wants to redirect users to Angular website but we want to pass the JWT token from A to B too, because the tokens are the same and we want to prevent user from logging in again.

Website A can send the token in a post request header while is redirecting to B. The problem is that JS (Angular) can't directly get the header parameters because they are sending to IIS.

The question:

1. Is there a way in IIS, we could get the token from the request and set it in html attribute while retrieving the index.html? so then, JS can check it's html elements and will find the token.

2. Is the above technique correct? if not, could you please give your suggestion?

Recreation

If you want to prevent user from logging in again , you have to store the token in local storage when logging in and clear it our on logout . Token can be stored using localstorage.setItem() and retrieved using localstorage.getItem. Using redirects even if you somehow get it to work , will be a problem if someone logged into site A and used another tab to login to site B (they will be asked to login again) – Debose

You couldn't do localStorage if they are separate domains. – Flavius

@mwilson, Missed that , thank you for pointing out . Will have to play with iframes and post message to a dummy page in domain where local storage needs which seems complicated than answer below . I just feel with multiple domains and redirecting form one domain to another , there will be issues with logout – Debose

That is an even worse idea. There is absolutely no need for iframes here (or ever). No, no no no no no no no no. – Flavius

IIS URL outbound rule can move token in request header to the html element. However, outbound rule only work when sender website return response to client. So IIS can't achieve your requirement. – Glennaglennie

Answer 1

We couldn't do this achivement only by IIS, finaly we wrote a simple Node.js application as a backend that when you call it, it loads Angular files.

Site A paases the token to the site B (which is hosting the Node.js backend) in the header through a Post request. Then the node application returns the token in the cookies.So when the angular application loads up, itreads the token from the cookies.

At last we put the Node application into the IIS.

Hope it helps other people.

Recreation

Answer 2

My thought process on this would be to redirect the user to the angular page with either a query param or a route param. It's just as secure/unsecure since anyone can see header values (if you're worried about exposing your JWT to the end user.

I would make your login page accept a JWT (or whatever your page that's being redirected to is)

So, let's say you do https://myangularsite.com/login?jwt=JWTTOKEN

Then, in your login page, you could grab that JWT Token from the url

const jwt = ActivatedRoute.snapshot.queryParamMap.get('jwt');

Now, you can put that value in localStorage:

localStorage.setItem('jwt', jwt);

Then, in Angular, just create an HttpInterceptor that grabs that JWT Token from localStorage and applies it to the header for every request:

const jwt = localStorage.getItem('jwt');
const request = req.clone({ withCredentials: true, headers: jwt });

You can kind of think of this as the same thing as when you sign up for some service and they send you a link via email to confirm your email. That link that you click on takes you back into their site with a Email Confirmation Token. When you hit that site with that token, it knows who you are from that token.

Ex: http://facebook.com/confirm?token=emailconfirmtoken

Flavius

Answer 3

The above answer is not correct that "It's just as secure/unsecure since anyone can see header values". Header values are encrypted in transport with TLS; whereas, URL query parameters are readable along the entire routing of a request. If security is a top concern, then do not place anything that could be considered sensitive as a query parameter.

Colorant