While I understand how jwt works for authentication, I'm trying to build registration.
Registration has a step that requires verification.
User enters the phone number
Code is sent via sms to user
User enters the code and device is verified
Since it's an API for mobile app there is no session/cookie built in.
I'm wondering if I can not implement cookie like system for mobile. And just make it work with JWT. But I don't have much experience with this.
This is my current flow:
User makes a POST request with Phone #
I respond with JWT (Time:Number)
I also send code via SMS
User sends the code via POST and JWT
Problem:
I don't know if code belongs to user or not, as I didn't save the code in DB.
I can't put into payload as it's just encoded not encrypted. (why is it not encrypted, what's the point of sending plain payload, what's even the point of JWT & didn't signed cookies already do that? they had session string encrypted so you couldn't change session string without invalidating the cookie)
JWT is overcome authentication/authorization mostly in APIs. JWT Access Token/Refresh Token is nothing but a JSON data in an encrypted form. JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA or ECDSA. Key pair using RSA or ECDSA is more preferable as a security point of view. You can check authentication/authorization by decryption JWTs.
JWT token itself contains expiry date, so you can just configure expiration time to it. Access tokens are to check that user is authorized or not. Refresh tokens is necessary to get a new access token, generally used when the old access tokens are expired. Refresh token and Access token both expire but refresh token is long-lived compare to access tokens.
Generally developers use access token only but it is preferable to use access and refresh token both.
I have a nodejs api with an angular frontend. The API is successfully using JWT with passport to secure it's endpoints.
I am now conscious that after the tokens have expired, my front end will still allow the user to request my api endpoints without prompting them to reenter their log in details to get a fresh token.
This is how my backend generates the token:
function generateToken(user) {
return jwt.sign(user, secret, {
expiresIn: 10080 // in seconds
});
}
So to implement this logic I think I need to verify the JWT token client-side. Q1, is this a sensible approach.
Q2, the JWT library I am using seems to require a public key to use it's verify() function. I don't seem to have a public key, only a secret, which I just made up, so it wasn't generated with a pair. Where does my public key come from, or is there another way of verifying my token without this?
This all seems like it should be obvious and that I have missed something, so apologies if this is a stupid question, but I can't seem to find the answer?
TL;DR
You must verify the signature of JWS in the server always.
Client-side signature verification doesn't gives much, unless you have a specific case where it makes sense don't do it.
You don't need to verify the signature of a JWS token to check expiration in the client. (unless you were encrypting the claims, aka using JWE, in that case you need to do something similar because you need a key to decrypt the claims).
You don't need to verify the signature of a JWS to check expiration in the server neither, but you should because this gives you the certainty that nobody has altered the expiration (otherwise the verification will fail because if the claims change then the recalculated signature will differ)
To read non encrypted claims you just only need to decode them. You could use jwt-decode in the client.
I am now conscious that after the tokens have expired, my front end will still allow the user to request my api endpoints [...]
So to implement this logic I think I need to verify the JWT token client-side
If I understood you correctly you are talking about checking if a JWS has expired in the client side.
In order to do this you don't need to verify the token signature (although the library you are using seems to be doing both things at the same time for you, but also lets you to disable expiration control with ignoreExpiration flag). (Unless you're encrypting the claims, aka using JWE)
The RFC 7515 (JWS) says nothing about expiration. Message Signature or MAC Validation doesn't control expiration (and it shouldn't because signatures gives you authenticity and integrity).
Even the RFC 7519 (JWT) doesn't control the expiration claim for resolve if a JWT is valid or not.
Also, all the claims are optional.
So, you could check if a JWT has expired or not without verifying the signature, hence you don't need neither a public key (for asymmetric encryption like RSA) or a secret key (for symmetric encryption like AES).
In JWT and JWS tokens, the claims are just plaintext base64 encoded so you could just decode the payload without verifying if the signature is valid and read the expiration claim.
If you are encrypting the payload (aka using JWE) then you will not be able to do this.
A note from jjwt library
JWTs can be cryptographically signed (making it a JWS) or encrypted (making it a JWE).
Here is a ligthweigth library from auth0 to decode the base64encoded claims of a JWT/JWS token.
A guy is even asking about checking expiration.
I don't know why you think that you should be doing this control client-side, the only advantage is avoiding sending API request that the client knows that will fail. And they should fail because the server should be validating that the token hasn't expired, previous signature verification (with secret/private key) obviously.
The RFC 7519 says about this claim:
The "exp" (expiration time) claim identifies the expiration time on
or after which the JWT MUST NOT be accepted for processing.
In a web app like the one you say the use of tokens is to allow stateless servers to authenticate client requests.
The goal of the OPTIONAL expiration claim is to allow the server have some control over the generated JWS (if we are using JWT for authentication signing them is a must so we should be talking about JWS).
Without expiration, the tokens will be valid forever or until the key used to signing them change (this will make the verification process to fail).
By the way, invalidating sessions is one of the most notorious disadvantages of using stateless authentication.
Session invalidation becomes a real problem if we are including information in the JWS payload (aka claims) used for authorization, for example which roles the user have.
From Stop using JWT for sessions
but more seriously, it can also mean somebody has a token with a role of admin, even though you've just revoked their admin role. Because you can't invalidate tokens either, there's no way for you to remove their administrator access
The expiration control doesn't solve this problem and I think is more oriented to avoid session hijacking or CSRF attacks.
An attacker using CSRF will be able to make a request with an expired JWS to your API skipping the expiration control.
A different issue is verifying the signature in the client using the public or secret key.
Regarding your question
I am using seems to require a public key to use it's verify() function. I don't seem to have a public key, only a secret, which I just made up, so it wasn't generated with a pair.
The verify method you pointed out says explicitlly that it accepts a public or secret key.
jwt.verify(token, secretOrPublicKey, [options, callback])
secretOrPublicKey is a string or buffer containing either the secret for HMAC algorithms, or the PEM encoded public key for RSA and ECDSA
I assume you are using neither and you are using a string like 'shhhh'.
var token = jwt.sign({ data: '¿Donde esta Santiago?'}, 'shhhh');
Then you should do
var decoded = jwt.verify(token, 'shhhhh');
However, the question here is: Is client-side signature verification really needed?
I think is not, at least not for this kind of application where the client just uses the JWS to send subsequent request to the server saying: "Hey server, I'm Gabriel and I have a paper (token) here that assures that and that paper is signed by you."
So if the client doesn't validate the JWS and a MITM had successfully gave to that client a JWS signed by himself (instead to the JWS signed by the server), then the subsequent request will simply fail.
Like expiration control, signature verification only prevent the client to make request that will fail.
Now, client side verification requires sending the public or secret key.
Sending public key doesn't represent a security concern but it's extra effort and processing with little benefits.
Sending secret keys (like 'shhhh') can represent a security issue because is the same key that is used to sign tokens.
I'll just put it here for those who got here looking for jwt verification on the browser with a public key.
Library:
https://kjur.github.io/jsrsasign/
Example:
https://kjur.github.io/jsrsasign/tool/tool_jwtveri.html
Code example:
https://github.com/kjur/jsrsasign/blob/master/tool/tool_jwtveri.html
API:
https://kjur.github.io/jsrsasign/api/symbols/KJUR.jws.JWS.html#.verifyJWT
P.S. Don't use your secret key for browser jwt verification! Public key only!
I think verifying JWT token at client-side is not a good idea.
IMO;
Whenever a user logs in, generate access and refresh token and return to user something like this;
{
"accessToken": <<accessToken>>
"refreshToken": <<refreshToken>>
"expiresAt": <<expiresAt>>
}
So client can understand when access token expire and can refresh it with refresh token.
Encrypt the data that you put in the access token because there is a chance to access the data without secret key. But of course someone needs to secret key to verify.
Q1: Token verification on client is a bad idea. What you can do is to save a token together with a same expired date on client and then refresh/remove a token. But my thought that it is better to have some date checkig on server side cause exist simple rule: Don't trust the client cause it can always send malicious code.
Q2: JWT don't need any public key. It always must have private key storing on server side cause if someone known your secret key your token don't make any sense. You only can add some payload to do it more complex.
Managing when the token expires on the client side so you can avoid sending tokens which you know will be rejected is purely an optimisation to avoid an extra roundtrip with the server. Its a perfectly valid concern but it's not a security concern. Its up to you to decide if you need that level of optimisation. The server must validate the token signature and reject expired tokens as a security concern. Tokens don't need to be encrypted unless they contain sensitive data that you don't wish to be visible to an end user or an attacker that obtains a copy of the token somehow. Tokens should be transmitted over HTTPS / SSL as good security practice. Access Tokens are usually short lived. If you also use refresh tokens, never store one in a browser unless it's a secure cookie set by the server for the same origin domain and not accessible to browser scripting. In that case Refresh tokens should still be regularly rotated.
Answer 1: It is not considered to be a good approach to verify your auth token on the client side as it involves secret key while encoding/decoding it and keeping the secret key on the client side is not secure.
Creating Token
jwt.sign({
data: 'foobar'
}, 'secret', { expiresIn: 60 * 60 });
Verifying Token
jwt.verify(token, 'secret', function(err, decoded) {
console.log(decoded.foo) // bar
});
Answer 2: JWT involves secretORPublic key while encoding and decoding token. It has to be declared or kept in the config file somewhere on the server side.
Explanation:
Decoding means decoding from Base64, there's no secret key involved in that process. On the other hand, verifying a JWT would require a secret key because it would involve a cryptographic signature operation.
To sum up, decoding does not need the secret (remember decoding is just interpreting base64) and verifying/signing does require it
I read that having a JWT system vs a simple token-based system eliminates token lookups in a database. But I don't get how that's possible. If it uses HMAC for a signature, doesn't the server need to look up the secret key for every client to verify their signature? Or do all clients use the same secret key? (sounds very insecure). If it uses an asymmetric algorithm, doesn't it still need to look up one of the keys to verify the signature?
In the usual scenario, the server requires the credentials to authenticate the user (i.e. user & password). If the authentication is successful, the server issues a JWT which is signed with server's private key, not by the client..
The signature protects the content and identifies the signer. Any alteration to payload or signature can be detected by the server verifying the signature and will reject the JWT . Therefore server can rely on the data included in the JWT
The server can include in the payload the claims needed for authentication, for example user id sub, exp and other claims of interest like the username, email or the authorization roles . See What to store in a JWT?.
{
"sub": "joe",
"iat": 1300819370,
"exp": 1300819380,
"email": "joe#stackoverflow.com",
"roles":["admin","finaluser"]
}
After verification of the signature, the server can use directly the included claims instead of query the database.
With a symmetric key (HMAC), signature and verification is done with the same key. An asymmetric key pair (RSA) is composed by a private and a public key. Signature is done with the private key and verification with the public. Use a asymmetric key when you need that the client verifyies the JWT.
JWT is mainly used for Authorization. Whenever an user succeed in authenticating using his password(which need a database lookup) JWT will be created. This JWT will contain payload which will mainly contain UserIdentification. So whenever User send sub sequence request to the server he will attach this JWT to the header. Using this JWT, server will find out that this user is already authenticated. But there is still authorization is there. Let say the user has requested service A. Now we know that User is authenticated so we can go to the access control table and see whether this user is eligible to make this service call. Or if we added the user authorized service details to JWT payload at the authentication step, now we can use the payload information to make the authorization decision instead of the database look up. It depends in the developer. You can use both ways to authorize the user.
You can use the same secret key for every client. And it's secure! The client never sees your key. What JWT allows you to do is verify that the payload was signed using the secret key, and as long as it's kept secret, you'll know that only you could have signed the payload.
I try to create a Web application with JWT:
If a user send a request the server, I can run the process on the server and send the data back to the browser in a web token, that brings me to the question:
How can I verify this server response in the browser and send a new request to the server by using JWT with a secrete that can be accept from the server?
On the server the JWT from the browser request should be verify.
My consideration is to create a JWT on the client with the same "secret" but this is readable for attackers, because it is possible to read the source code (developer console).
Does there exist an way?
//Create request JWT
Request 1 --> {head: ...; data:..., secrete: secret}
//Request should be checkted on the server (secrete)
// create a Resonse JWT and send back to the Client
Resonse 1 --> {head: ...; data:..., secrete: secret}
//Client verify the Respons JWT by the secrete
Keep secret the private keys. Sending them along the net is a dangerous solution because if they are stolen break the full system. You can use an assymetric RSA key pair instead of a symmetric. The JWT is signed with the private key and verified with the public
In the usual scenario, when user is not identified, the server requires credentials to user in the browser, and issues a new JWT token. The client application in the browser include the JWT token in subsequent requests to authenticate. The server verifies token signature.
You propose that the browser also issue JWt tokens as a form of authentication. Consider the following:
you will need an assymetric key pair
generate the keys in the browser, do not send the private key by network
keep the key safe: I suggest using the native webcryptography api, because unlike any other cryptographic library, allows to generate and use keys without exposing the content, ie can not be stolen
send the public key to server and associate it with the user's account
I have a requirement to secure my JAX-RS resources and only accept requests that originate from authorized mobile applications. Is this possible? How can this be done?
All of my resources are protected already with user authentication, the goal here is to reduce user ID fishing attempts. I know one solution would be to keep the response error with an invalid user ID generic, but the application is very large and at the moment this isn't possible.
One idea I came up with is to use JWT tokens signed with a shared secret. Then I could add an Authorization filter on the server to check the signature. If it doesn't validate then discard the request. Does this sound like a viable option?
My concern is the security of the shared secret on a mobile device, could it be compromised with a rooted device?
Using tokens is the preferred way. But the secret key is not shared. Only the server has access to it. That secret key is used to generate the message authentication code(MAC) of the JWT. Since secret key is only known by the server, no one else can generate a JWT with a valid signature. Secret may be persisted or application scoped.
Once a client is authenticated using credentials, server must send a signed JWT to the client.
That JWT must contains necessary information to identify the client and state(if necessary).
Then client send that token in a header field along with all the other requests.
Server validates the JWT using secret key and process the request.
Even though client can change the JWT body, he cannot get it verified. That's the whole point of using a signature.