Whoever possesses the private key can create valid tokens where your system simply can not distinguish between a legitimate token and a token created by the attacker.
I am guessing you are not just using the expiry field but also the subject field sub, which is in short terms the logged in user.
With the private key, I can create a token with any subject I ...
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 ...
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 ...
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. ...
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 ...
tl/dr: Although you could store the balance in your JWT and it would
be safe from tampering, there are many ways in which the balance in
the JWT might be technically valid but still incorrect. Therefore, you are probably best
off checking the balance in the database everytime, and you certainly
need to check it before making any transactions
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
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 ...
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 ...
Yes you should query the database on each request. Using a JWT approach means you're relying on the client to send the correct JWT. If you're suggesting storing balance on the JWT then I presume that your idea is to generate a new JWT each time the balance changes. The problem is trusting the client to send the correct JWT.
00:00 - I access the ...
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.
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 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 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 ...
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:
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-...
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-...
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 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 ...
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 ...
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 ...
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 ...
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
These are probably the parameters of an RSA key, as you can see here: https://www.gnupg.org/documentation/manuals/gcrypt-devel/RSA-key-parameters.html
The naming convention matches with that one used in the JWK:
RSA public modulus n.
RSA public exponent e.
RSA secret exponent d = e^-1 \bmod (p-1)(q-1).
RSA secret ...
The short answer is to use RS256, to be understood as SHA 256 with RSA 2048 bits keys.
See RFC 7518 JSON Web Algorithms (JWA) for all supported algorithms.
On signing algorithms
There are two major signing algorithms supported by JWT: RSA and ECDSA.
RSA (as in alg:RS256) is the classic asymmetric signing algorithm based on prime factorization. It's very ...
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 ...
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....