tl/dr: Your selected version of the JWT doesn't encrypt anything, it merely encodes it for easy
transport. The data in the payload is not meant to be a secret.
You have a JWS (JWT with signature). What you are looking at is simply the base64 encoded data payload. A JWS contains 3 parts:
The base64 encoded header
The base64 encoded data
A cryptographic ...
JSON Web Tokens (= JWTs) are based on the RFC 7519 and all differences will be extensively described there. If you take a look at this, you will see, that they are much more than what you seem to have in mind.
Among other things, these tokens:
are used to assert claims (for instance "logged in as admin")
are signed with a message authentication code (e.g. ...
Refreshing a token is done to confirm with the authentication service that the holder of the token still has access rights. This is needed because validation of the token happens via cryptographic means, without the need to contact the authentication service. This makes the evaluation of the tokens more efficient, but makes it impossible to retract access ...
There's a bit of confusion of terminology here.
JWT defines the basic format of the claims, and some standard claims. It specifies that the JWT Claims Set should either be the payload of a JWS or a JWE structure.
JWS defines a structure for some payload with a signature. While the payload is almost always JWT in practice, this is not a requirement of the ...
The jti claim as described here is an optional mechanism for preventing further replay attacks. From the spec:
4.1.7. "jti" (JWT ID) Claim
The "jti" (JWT ID) claim provides a unique identifier for the JWT.
The identifier value MUST be assigned in a manner that ensures that
there is a negligible probability that the same value will be
SAML and OAuth 2 are protocols used in authentication/authorization. JSON Web Tokens (JWT) is a specification for a token that can be used in many applications or protocols - it happens that the OpenID Connect (OIDC) protocol uses the JWT. SAML also defines its own token: SAML Assertion; as does OAuth 2: Access Token. Tokens used by these protocols denote ...
A JWT, if used without Cookies, negates the need for a CSRF token - BUT! by storing JWT in session/localStorage, your expose your JWT and user's identity if your site has an XSS vulnerability (fairly common). It is better to add a csrfToken key to the JWT and store the JWT in a cookie with secure and http-only attributes set.
Read this article with ...
JWT are only an encapsulation of information into a string with the ability to encrypt these information and detect tampering. JWT by themselves don't protect against cookie theft or misuse done with sniffing, XSS, CSRF, browser extensions or similar.
This means you still need to employ the usual methods to protect the token or cookie against misuse, i.e. ...
How bizarre! I asked basically the same question about a month ago.
In the end, we decided that using localstorage for the JWT token was ok, as long as we also did the following on the HTTP level:
Ensure the entire site was served over HTTPS
Ensure the use of HSTS
Ensure that, once live, only the actual redirect URL was included in the Auth0 rules, as well ...
What you're missing is that your token is signed (or, more precisely, authenticated with a symmetric key) but not encrypted.
If you take the token in your question above, split it into three pieces at the periods (.) and feed each piece into a base64 decoder, you'll get the following decoded outputs:
You should refresh the token every 15 minutes, but you don't need to let the user authenticate again to do so.
After authenticating, hand out a JWT that is valid for 15 minutes.
Let the client refresh the token whenever it is expired. If this is done within seven days, a new JWT can be obtained without re-authenticating.
After a session is inactive for ...
There is no need to encrypt the token or to include the nonce. The key properties of a CSRF token are that it is not predictable by an attacker, and, unlike cookies, that it is not added to every request by the browser. A cryptographically secure JWT stored in a hidden field meets both of these properties.
Note that you need to use JWT's that have user-...
I believe you are asking two questions:
does changing payload invalidate signature: TL;DR: yes
does adding encryption over JWT give you authenticity of content: TL;DR: don't encrypt yourself, use JWE!
Here are the answers in more detail:
(1) According to the specifications,
the signature of a signed JWT (JWS) ...
You are doing a conversion from hex encoding (or base16 if you like) to base64. So you are base64 encoding the ASCII characters 9 (57), B (66) and 2 (50) giving you OUIy.
What you should be doing is base64 encoding the raw bytes. So you should encode 0x9B (155) and 0x23 (35) giving you myM.
From my other sec.SE answer:
JWT are self sufficient tokens which are used to share authentication information between different systems. They solve the problem of relying on third parties for validating an authentication token as all the information required to validate the JWT is contained within the token itself. This simplifies the process of on-...
If the request to the 3rd party API is through your server, then store the access token in the database tied to the user, encrypted with a key that is stored as an environment variable. If the database is compromised, the tokens are safe. (Bonus, encrypt the tokens with a key that is generated and stored on the mobile app.)
If the request to the 3rd party ...
There are a few things that will mean exploitation is unlikely.
To start with
is an invalid combination:
Important note: when responding to a credentialed request, server
must specify a domain, and cannot use wild carding. The above example
would fail if the header was ...
You seem to be mixing up several different opposing technologies, and do not make it clear why you have chosen these technologies and why they control the threats you are trying to secure against.
JWTs are stored in an access_token cookie. They are first signed then
encrypted using jose-jwt.
Is there any reason why they are encrypted? Signing is used ...
I ended up writing a little Python script that uses PyJWT to parse the JWT and check the signature.
There is also jwtbrute. I haven't tested it, but it seems to be a bit more efficient than my script because it does much work such as base64-decoding outside of the loop.
If you want to crack JWTs using John the Ripper, you need to convert their format to ...
One of the main criticisms of stateless session tokens is the lack of a secure logout. Having a separate access/refresh token allows a compromise. You can greatly reduce the amount of database access, while having a secure logout function with a 15-minute delay.
The design doesn't do anything to protect against session hijacking, i.e. malicious capture of ...
Are there any caveats to this approach? (security-wise)
Yeah, it's not very thorough, you can get a new instance of the constructor from a new window object instead:
XMLHttpRequest = null;
var iframe = document.createElement('iframe');
iframe.style.display = 'none'; // optional
var XHR = iframe.contentWindow....
Consequently, stealing the CSRF token is the least of your worries -- the XSS allows anything on the same origin that a CSRF would ...
I'm assuming you are using some proprietary authentication solution, which is using JWT and refresh tokens but has nothing to do with OpenID Connect.
JWT tokens are stateless, refresh tokens are usually statefull.
You should look at advantages and disadvantages of statefull vs stateless tokens:
Stateless tokens can be validated without extra DB/Service ...
JWT, if hashed and encrypted strongly enough, are just as secure as sessions and bring lower overhead. Just make sure to keep it small(although if you're doing anything that requires more than a few KB of storage you're probably doing something wrong...). Follow the best practices for session with JWT and you'll be fine.
If you use a strong enough algorithm ...
As Robert said, a jwt can be just as secure as a session if it is encrypted good. Make sure the secret you use is very unique.
WARNING: There is a vulnerability with some json web token libraries that use Asymmetric keys.
node-jsonwebtoken, pyjwt, namshi/jose, php-jwt or jsjwt with asymmetric keys (RS256, RS384, RS512, ES256, ES384, ES512). These are ...
I hesitate to roll my own security, but just for the fun of it here is an idea.
Instead of including the password hash, follow this process when generating the JWT:
Obtain the password hash
Obtain a server-side secret key (256 bits entropy should do it)
Compute an expiration timestamp, say an hour from the current time
Create a new hash over 1 + 2 + 3
Suppose there are 2 servers: TRUSTED (e.g Google) and UNTRUSTED (any site that allows 'Sign in with Google').
I don't want to send my TRUSTED username and password to UNTRUSTED. I also don't want to make a separate username and password for UNTRUSTED.
So instead I get TRUSTED to authenticate me, and send a signed JWT containing my identity to UNTRUSTED to ...
The point of having access tokens is that they can be used without checking for invalidation. You can have 10000 frontend servers users can access with the token without the need to ever ask some database if it is invalid. But after some time, the token expires. The user needs a new access token, sends her refresh token and this refresh token is checked in ...
You have to ask yourself what you try to protect against (you mentioned issues like session hijacking) and in what environment.
IF you want to only store a session identifier on the client side, JWT does not give you anything, that is not already provided by the typical cookie-based sessions.
The problem that is solved by JWT is that session data can, if ...
"Shared secret" in this case typically means between multiple servers, not between the client and the server. Typically, JWTs can be done using symmetric encryption - in which case all servers that need to verify the token need to have the shared secret - or asymmetric encryption, in which case only the server actually doing the authentication needs to have ...