I've been reading several articles recently about how storing JWTs in local or session storage is inherently insecure. The mitigation is apparently to implement a "session ID pattern", i.e. create a session ID, which is stored in a signed HttpOnly cookie and is also included in the JWT, in which case both can be compared server-side to make sure the token corresponds to the right session.

From my limited understanding of the OpenID Connect spec, it seems like that session pattern is part of the specification (as state parameter), so I'm assuming that using a compliant implementation should be enough to protect against CSRF/XSS in this particular context.

Is this a correct assumption? Does OpenID Connect spec include CSRF and XSS protection for JWTs?


Binding a JWT token to a session does not protect from CSRF and XSS attacks. The OpenID Connect specification does not include CSRF and XSS specifications, and it conceptually just cannot include it.


An attacker tricks a user to click on a button, image or link, that triggers some malicious action like transfer $1000 to some account., where as user is not aware of this action. From the server point of view the request will be absolutely correct. In particular, the session ID from httpOnly cookie will be present and valid, also the JWT token will be present, valid and will refer the valid session ID. Thus the server will execute the request.

To protect from CSRF a request should contain something that only server knows, what attacker doesn't know. There are different techniques (synchronizer token, cookie-to-header token, etc.) In all cases this part of the content is provided by the server itself, not by the 3rd party service that issued JWT token.


XSS leads to generation of DOM and/or Script that causes undesired behaviour. Again, from the server point of view any such request will contain valid session ID and valid JWT token.

The protection from XSS includes filtering of input and, on client side, escaping of response elements that are not expected to be DOM elements. JWT does not help to protect from XSS.


OpenIDConnect spec is describing ONLY the authentication process. To protect this process OpenIDConnect (or more like OAuth2 spec) defines the state parameter which is provided in Authorization Request. Client is sending state value to Athorization Server (AS) and AS is getting back with response including the same state value (nevertheless it is successful or not).

The state value prevents the CSRF attack on client app, confirming that value comming from response matches the value sent in initial request. In this case the attacker will not know the state value and will not be able to send to client any payload (for example with malicious token).

But as I stated at the beginning, it secures the authentication process only.

XSS is the vulnerability which can lead to CSRF attacks and is more related to how application handles the input (filtering) and output (encoding) data. OpenID Connect is not responsible for mitigating such an attacks.

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.