Authentication with JWT

2
votes

I've been following this blog post (https://auth0.com/blog/2015/04/09/adding-authentication-to-your-react-flux-app/), and am confused on an aspect of JWTs.

The post above seems to test if the user is already logged in by checking to see if there is a JWT stored as a cookie, and if so, it simply decodes it to find the username and other information, and redirects the user to the authenticated page.

I'm wondering what is stopping someone from adding a fake JWT cookie to gain access to an authenticated portion of the app? I must be missing something obvious. In other words, when maintaining a session, how does the frontend ensure that the JWT is one that was "signed by the server" or something, and not one that was fraudulently created to try to gain access?

2
javascriptauthenticationcookiesjwtjson-web-token
"I'm wondering what is stopping someone from adding a fake JWT cookie to gain access to an authenticated portion of the app?" --- what key would you use to sign it? – zerkms
So when a JWT is stored as a cookie on the frontend, before satisfying any request, the server checks if that JWT is signed with its key and if so, allows it? – sir_thursday
"the server checks if that JWT is signed with its key and if so, allows it?" --- yes. In other words - you cannot trust anything sent from the client. – zerkms
Hm.. I guess I am confused because the tutorial I'm following (or the repo linked to it) doesn't seem to do that when the app is refreshed and the user has previously signed in. It seems to just check localStorage for a jwt, and if so, authenticates the user. – sir_thursday

2 Answers

3
votes

In many apps, someone can add a fake JWT to gain access to parts of the front end that you only want them to see if they are logged in. But then, they also have the front end running on their own computer and can change the code to do the same thing.

The back end server encoded the JWT using a key that should not exist on the front end, and when you pass the JWT back to the server the server will decode it BEFORE processing your request. So it knows that someone used your login credentials earlier, that it sent out the JWT in response, and that someone is sending it the JWT again. This blocks attacks on your API from people without the (real) JWT.

It also has advantages over session cookies in that it is stateless on the server side and it makes certain cross-site request forgery attacks harder in traditional browsers because an attacker can't embed a request to your site and trust the browser to add your session cookie.

But it's only one part of a larger security solution.

2
votes

The key here to JWT's security is the "secret"-- a key that should only be on trusted servers (or with your authentication provider, if using a third party). JWTs are encrypted using this secret. It can be a passphrase, but JWT also supports public/private key encryption, so the secret can also be a private key.

So, in your case, what's preventing the user from creating new JWTs on their end is, unless they know the secret, the encryption they use to create their own JWT will not work on the server, which, if coded correctly, will prevent the user from authenticating the way they wish to.