1

We are using Keycloak for the authentication of our server-side rendered applications (Java/Spring/Thymeleaf), and now we want to use it for our Angular applications.

Using the Angular quickstart, the token is set in the Authorization header (as you can see below). My question may sound dumb, but since Javascript will always be able to access the token: isn't it a huge vulnerability? (in case of XSS)

Would it be better to use a http-only cookie?

Example of request to the API using the Angular quickstart:

- Request URL:
https://my-app.com/my-resource

- Request Method:
GET

- Response Headers 
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: https://my-app.com

- Request Headers 
Authorization: bearer eyJhbGciOiJSUzI1N.............
Origin: https://my-app.com
Referer: https://my-app.com/
User-Agent: Mozilla.............

Link to the angular quickstart: https://github.com/keycloak/keycloak-quickstarts/tree/latest/app-angular2

0

First of all, yes, an XSS vulnerability will allow an attacker to access the bearer token in the authentication header. But this alone isn't the full story.

Your decision, if you want to transfer the bearer token as authentication header or as cookie, is based on multiple factors:

  1. How large is your token? Cookies are limited to 4kb. If you transfer many and/or large claims in your token, this space might not be enough. In such a case, the authorization header is the logical alternative.
  2. Are you protected against CSRF? When you transfer your authentication tokens as cookies, you open yourself up to potential CSRF attacks. If you go this route, you must be even more careful to verify your application's resilience against CSRF.
  3. Why do you fear that your bearer token is stolen via XSS? May sound like a stupid question, but it is highly relevant. Your application has a sever issue, if you are vulnerable to XSS, period. Stealing your bearer tokens is only the tip of the iceberg. Yes, adding the http-only flag to your sensitive cookies is a second line of defense, but your first priority must be ensuring that you do not have an XSS vulnerability in the first place. Putting your bearer token in a http-only cookie is no excuse for a lack in protection against XSS.

In summary it can be said, that both options (cookie and authentication header) are accepted methods and both have their benefits and drawbacks. Which one is the better choice, depends on the surrounding factors.

| improve this answer | |
  • Thanks for your answer, for 1. and 2. , quick answers are "far less than 4kb" and "yes". For 3. , I dont agree at all: security is about multiplying defenses, not just closing one door – Nicolas Mar 14 at 21:02
  • @Nicolas - I fully agree that you need layered defenses and adding a second line of defense is great. All I am saying is, please make really sure that you are safe against XSS, because protecting the bearer token alone is not enough. So yes, sending the access token in a http-only cookie would be a good solution for your scenario, given the parameters you describe. – Demento Mar 14 at 21:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.