Shivam Yadav
Shivam Yadav

Reputation: 19

Is using JWT for API request weak because the user is in possession in the token and can re-use it?

The only security JWT provide is like their generated tokens are valid for like few seconds or minutes (we can set that) but when user sends are request with generated JWT token , a hacker can easily listen to the request in browser -> inspect -> network and replay the attack, even if the token is valid for only 30 seconds that’s still a lot of time to replay the attack.

I tried sending my request with encrypted payload, the hacker may not be able to view the payload but he can still replay the attack to mess up my functionality/calculations.

Upvotes: 0

Views: 71

Answers (2)

Sergey Beltser
Sergey Beltser

Reputation: 1

I believe there are no security measures that can help you if a hacker has direct access to the client's browser. But if a hacker is somewhere between the web browser and the server, then:

  • Simply use HTTPS and additionally encrypt the token (using JWE on top of JWT).

  • To prevent request replay attacks, generate a unique idempotency key for each calculation request. Use JWT or another protocol. Track blacklisted (used) tokens in the database. Thus you will be sure the request processed only once.

Philosophically, I agree with @VLAZ that user authentication and request genuineness/uniqueness should be separate concerns.


If you need to scale the solution, I propose the following algorithm:

  1. When a user sends a request for calculations, first send a request to obtain an idempotency key with a short expiration time (30 seconds).

  2. Send the request for the calculations themselves.

  3. On the server, check the token's expiration time and verify that it is not blacklisted (previously used) in the database (SQL, Redis).

  4. Run a background job on the server to remove expired tokens from the database (since requests with such tokens will fail the expiration date validation and are already blocked).

Upvotes: 0

Lajos Arpad
Lajos Arpad

Reputation: 76953

You can make your JWT available for once only, so after it's sent to the SP, it will instantly be invalidated and will no longer be accepted. This would mean that your SP will need access to your blacklisted JWTs too.

Of course, you will likely need to embed a refresh token inside the JWT so the SP will be able to back-send requests to the IDP.

So, the algorithm on the IDP:

if session does not exist then
    try to authenticate the identity
end if
if the identity has a valid session then
    send out a JWT
    synchronize with the SP
    once the JWT has been received, invalidate it
end if

And at the SP

send request to IDP
receive JWT
if valid, then
    authenticate
end if

Upvotes: 1

Related Questions