4

I want to add authentication to my application using jwt tokens.

Every time I send request to the server I attach the token that my server created.

I wounding, is this secure way to send the token in the headers? what if somebody access to my computer and check my network in devtools tab and see my token, he can mimic the request with the token and take control the user data.

Is this common scenario? and the ways for stole and hacking jwt tokens?

Jon Sud
  • 10,211
  • 17
  • 76
  • 174
  • 1
    Use HTTPS and you'll be fine. Yes, if people have access to your computer they can always steal your (short-lived) credentials and sessions. – Bergi Aug 03 '20 at 07:05
  • I'm using HTTPS. so its safe to use although somebody can access to my computer and see the token? – Jon Sud Aug 03 '20 at 07:09
  • 1
    No, someone else accessing your computer and inspecting your network traffic is not safe, but that's not something tokens vs other forms of authentication can help solving. They'd steal your session cookies instead if your application was using that. – Bergi Aug 03 '20 at 07:16

3 Answers3

5

Yes its common to attach the token to the header. It looks something like this:

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

Sure somebody could go into your computer and check the token. But usually your computer has some kind of authentication aswell to log in. Same with phone, almost everybody has some kind of password.

A good way to store tokens are httpOnly cookies. With this flag javascript cannot read the cookie on the client side. It makes XSS attacks harder to get the token.

The problem about JWT are that they have a expire date and they are valid till they reach the date. Lets say you log in into a webpage, and get some token. Now somebody steal your token. You log off and erase the token form your device.

The problem is now that the token is stolen and still valid so the attacker can use it.

At this point the attaker is technically you because he has the token with the saved data in it.

What you can do here is to create a blacklist. If you log out you put your token into the blacklist. Whenever somebody try to access something that requires a token, you first check if that token is inside the blacklist, if it is you reject the request.

For a blacklist i would recommend a cache like redis for fast access.

bill.gates
  • 14,145
  • 3
  • 19
  • 47
  • @MedetTleukabiluly no its not lol, i am gonna edit it with a real one – bill.gates Aug 03 '20 at 07:11
  • it always starts from `eyJ` – Medet Tleukabiluly Aug 03 '20 at 07:12
  • @MedetTleukabiluly for some reason i have mistaken it with a password hash – bill.gates Aug 03 '20 at 07:19
  • @Ifaruki Like your answer. Curious 1) Is there a blacklist-like at server side? 2) Once user logs out, say suppose to acknowledge server _I'm out for the day._ Can server remember the last token and invalid request from this acct until a different new token is submitted? – Jeb50 Jun 12 '21 at 03:56
  • 1
    @Jeb50 the problem about JWT is that once they are created they are always valid until they expire. Imagine some third person has your token. He could authorize himself as you. To "invalidate" that token, you will need to add it to save this token in a list, like an cache whenever you log out. After making the request now, you need a pre-step befor fetching the data. you first check if that particular token is on that list. If it is, you deny access – bill.gates Jun 12 '21 at 08:19
  • Good solution and make sense! – Jeb50 Jun 12 '21 at 17:38
  • @Jeb50 the "blacklist server" is just a database on the serverside where JWT tokens are saved. to your question 2: When you log out, you save your JWT into the blacklist server. When somebody stole your JWT and tries to log in with it or try to do something with it it wont work because this JWT is on the blacklist – bill.gates Jan 31 '23 at 08:23
  • why would a hacker wait until you log off? – Joeri Mar 02 '23 at 19:04
1

The token is a short-lived key. Anyone with access to the token has access to whatever that key unlocks. It feels insecure, but this is a fundamental property of using tokens. You use HTTPS to encrypt the data so that it can't be read along the way, but there's always going to be ways for people to obtain the token.

There are often trade offs between ease of access and security. People have accepted the risks associated with using tokens for authentication. To be clear, any authentication method that stores a key has this problem; the only real alternative is to ask for the password for every request, but ain't nobody got time for that.

Multihunter
  • 5,520
  • 2
  • 25
  • 38
-1

This is the way that it should happen. In JWT token authentication, the server-provided token should always be sent as a header with the Authorization: Bearer <token> format.

The website then should check the validity of the token when a request comes and handle it accordingly.

EDIT

Yes, the use of HTTPS is mandatory. If a person gets hold of your computer, then they can use the token to impersonate the user.The good thing about tokens is that they are mostly short-lived, which means they expire fast. Hence halting their usage, requiring reauthentication.

Minasie Shibeshi
  • 390
  • 3
  • 16