How can we access cookie provided from authentication server in application server?

Question

I was reading a blog in angular (https://blog.angular-university.io/angular-jwt-authentication/)from its official website wherein for authentication a separate server is used and for application different server is used. So, in this case cookie will be issued by authentication server but will be used in application server. How is that possible? I am not able to understand the below explanation from that blog:

Cookies and Third-Party Authentication providers

A potential problem with receiving the session JWT in a cookie is that we would not be able to receive it from a third-party web domain, that handles the authentication logic.

This is because an application running on app.example.com cannot access cookies from another domain like security-provider.com.

So in that scenario, we would not be able to access the cookie containing the JWT, and send it to our server for validation, making the use of cookies unfeasible.

Can we get the best of the two solutions?

Third-party authentication providers might allow us to run the externally hosted login page in a configurable subdomain of our website, such as for example login.example.com.

So it would be possible to get the best of all these solutions combined. Here is what the solution would look like:

• an externally hosted login page running on our own subdomain login.example.com, and an application running on example.com
• that page sets an HTTP Only and Secure Cookie containing the JWT, giving us good protection against many types of XSS attacks that rely on stealing user identity
• Plus we need to add some XSRF defenses, but there are well-understood solutions for that.

Someone please explain the below line:

Third-party authentication providers might allow us to run the externally hosted login page in a configurable subdomain of our website, such as for example login.example.com.

What does this mean and how can we implement this on authentication server and how can we access the cookie issued by authentication server in application server. Please clarify if it means setting the domain field as application server in cookie issued by authentication server, or it is something else.

Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>; Secure; HttpOnly

Also, if this is the case how an application server validates the cookie provided by authentication server. Does authentication server also send this cookie to application server? Do we also have to put that mechanism in place?

Answer 1

Your question is kind of vague to me with a lot of different questions.

This is because an application running on app.example.com cannot access cookies from another domain like security-provider.com.

Cookies are only sent to the domain they come from. So two application on two different domains can't access each other's cookies.

Third-party authentication providers might allow us to run the externally hosted login page in a configurable subdomain of our website, such as for example login.example.com.

A solution to this problem is to put the two application on the same domain using subdomains. app.com and login.com can't access each other's cookies. app.example.com and login.example.com can because they are both on the domain example.com

There are also other solutions that are used by oauth for example. I'll give a summary of how that works but I suggest you look into the details yourself.

Assume we have app.com and login.com.

1. The user visits app.com and is not signed in. The user clicks on the login button.
2. The user is redirected to login.com?application=app.com
3. The user logs in using their credentials
4. login.com redirects the user back to app.com with a session in the URL: app.com?session=123
5. app.com can use the sessionid to obtain information about the user from login.com

Answer 2

As Robin correctly states, using a subdomain is kind of a way to handle the same-origin / CORS policy. This might not work for all scenarios - for example in my case we wanted to use the AD company accounts for authenticating users, instead of having to create additional accounts. Plus getting some additional benefits like separating user management from the application. You can do this in the case of AD users with MS Azure, and it works basically like described with forwards and redirects. In our case we put the JWT Bearer Token in the HTTP Header and do not use cookies. The backend gets the JWT Token in the HTTP Header with every REST request, and can validate it by decrypting it, using the public key of the Authentication provider. The Token can carry additional information besides user-id, like friendly name, email or user roles for authorization in the backend. The whole thing took us some time to implement and is not a trivial task, even if you use a Third Party provider instead of your own OAuth instance.

Answer 3

Just to add to the other 2 (correct) answers, there are a few reasons that cookies cannot be shared between domains. They all boil down to the same issue: the inner data is private, If this wasn't enforced, then logging in would be a lot less secure. Anyone could write a simple script and access not only jwt tokens but user data as well. Another reason is because the user only gave permission for the first domain to own the user datadata within.

Answer 4

There is 3 core concepts:

1. app.example.com can not read cookies of security-provider.com domain. Security restriction.
2. You can not read HttpOnly cookie via js.
3. You need to implement a proxy application on the same domain because of #1 and #2.

Simply speaking, what they are telling you is to create a new login-only page on your sub.mydomain and communicate with the main application on mydomain as setting a cookie on sub.mydomain with domain=mydomain will be accessible on mydomain plus XSRF and vice versa.

A short article on how we did handle the cross-domain communication in 2015, might be interesting to read.