Is the Authorization Header a Better Choice for CORS Issues Than Cookies?

JWT.io
1

Hello, I found an article on (JSON Web Token Introduction - jwt.io) website about JWT, cookies, and Authorization.

However, it states, “If the token is sent in the Authorization header, Cross-Origin Resource Sharing (CORS) won’t be an issue as it doesn’t use cookies.” This made me wonder why cookies exacerbate CORS issues.

I did some research on Google, and from what I understand, if the server (like in Spring) does not set setAllowCredentials(true), CORS issues may arise, thus using the Authorization header to pass the JWT might avoid these CORS problems.

In website statement, “If the token is sent in the Authorization header, Cross-Origin Resource Sharing (CORS) won’t be an issue as it doesn’t use cookies,” does it imply that using cookies leads to CORS issues because of the need to set setAllowCredentials(true)?

2

The statement from jwt.io is somewhat oversimplified. Here’s what’s actually happening:

  1. Cookies and CORS: When you use cookies for authentication, browsers enforce additional CORS requirements:
  • The server MUST send Access-Control-Allow-Credentials: true
  • The Access-Control-Allow-Origin header CANNOT be * - it must specify exact origins
  • The client must set credentials: 'include' in fetch/XHR requests
  1. Authorization Header and CORS: When using Authorization headers:
  • No need for Access-Control-Allow-Credentials
  • Can use Access-Control-Allow-Origin: *
  • Simpler CORS configuration overall

So yes, the statement essentially means that cookies require additional CORS configuration (like setAllowCredentials(true)) while Authorization headers don’t. However, it’s not that cookies “cause CORS issues” - rather, they require stricter CORS settings for security reasons.