Authentication FundamentalsLesson 1.4

Bearer tokens and the Authorization header explained

Authorization header syntax, Bearer scheme, token extraction in middleware, localStorage vs memory storage, XSS risk, header vs cookie comparison

Bearer Tokens and the Authorization Header

When you are not using cookies, tokens travel in the Authorization HTTP header. The standard format is the Bearer scheme.

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

The word "Bearer" signals the auth scheme. Everything after the space is the token itself. The server strips the prefix and validates the token string.

In Express, reading it looks like this:

function extractToken(req) {
  const header = req.headers['authorization'];
  if (!header || !header.startsWith('Bearer ')) return null;
  return header.slice(7);
}

Where to store the token on the client is a real debate:

localStorage / sessionStorage: Easy to access in JS, but any XSS vulnerability exposes the token to attacker scripts. No automatic expiry mechanism.
In-memory (React state, module variable): Gone on refresh, but invisible to XSS. Combine with a HttpOnly cookie for the refresh token for a solid setup.

The Authorization header approach is standard for REST APIs consumed by mobile apps or SPAs where cookies are impractical. For browser-only apps, the HttpOnly cookie approach is generally more secure because it removes token access from JavaScript entirely.