JWTs are particularly useful when an application is completely stateless.

The application itself is not stateless and uses sessions.

A combination of session tokens and JWTs can therefore be very useful depending on the application.

When stored in the browser’s cookies, it is possible to set the “HttpOnly” flag (and “Secure”),

to get protected against token theft in case of XSS attacks.

Sequence of checking permissions with JWTs

Sequence of checking permissions with session tokens

Registered claims : iss (issuer), exp (expiration time), sub (subject), aud (audience)

{ alg: "HS256", typ: "JWT" }.{ iss: "my-site.auth.com", aud: "my-site.com", exp: 1435937883,

id: 1234567890, username: "Denis Dekh", roles: ["Admin"] }.S9Zs/8/uEGGTVVtLggFTizCsMtwOJnRhjaQ2BMUQhcY

"How to Prevent:"

· Store the token using the browser sessionStorage container.

· Add it as a Bearer HTTP Authentication header with JavaScript when calling services.

· Add fingerprint information to the token.

How to Prevent:

A way to prevent it is to add a "user context" in the token. A user context will be composed of the following information:

· A random string that will be generated during the authentication phase.

· It will be sent to the client as an hardened cookie (flags: HttpOnly + Secure + SameSite + cookie prefixes).

· A SHA256 hash of the random string will be stored in the token (instead of the raw value) in order

· to prevent any XSS issues allowing the attacker to read the random string value and setting the expected cookie.

By storing the token in browser sessionStorage container it exposes the token to being stolen through a XSS attack.

However, fingerprints added to the token prevent reuse of the stolen token by the attacker on their machine.

To close a maximum of exploitation surfaces for an attacker, add a browser Content Security Policy to harden the execution context.

This secret key is kept only by application server and okta /some authorization server

Using this final jwt key can be generated and validated.