1

I read about JWT and how they can provide secure authentication for calling api routes over http. I naively implemented it and here is how it goes :

  • a client posts username and password to a login route
  • the server checks if the credentials are ok, creates the token and sends it back
  • the client keeps the token and adds it to any protected api calls

Now say I can see all client http in/out calls. As the password is clear in the first call I would just have to see if the response looks like a legit JWT and I would be pretty sure that the credentials are correct. If the password is encrypted on the client any attacker can decrypt it (just look at the source on the client).

What I am missing here ?

    2 Answers 2

    3

    What I am missing here ?

    "s".

    You need to be using https, which is end-to-end encrypted, not "raw" http.

      0

      This isn't an answer about how to program it yourself, so I apologise if I come off as unhelpful, but one thing I've had drilled into me over and over again by people who specialise in solving problems like this is get someone else to do it. You're right, the simplest possible implementation is not secure. All the specific things you need to do to make it secure are a whole application, perhaps a whole career, in themselves. If your project is to make a web application, then you're probably good at making web applications, and that's what you'd like to be doing - so why not let someone who likes making secure authentication take care of this part for you, so you can get back to working on your own application logic?

      My understanding is that this is one of the key reasons JWTs were invented - to facilitate the offloading of authentication to a third party. Your app presents the mechanism for the user to securely send their authentication info to their own well-secured server; the third party server then does all the work, and returns the token which your site takes to mean "this user is authenticated". This way, you don't need to worry about securing users' secrets from outside threats, and you don't need to worry (as much) about every possible security error in your code that could compromise your own application, either. Specialisation is one of the most important parts of a highly industrialised society - you don't feel obliged to install the wiring in your own datacentre, or increasingly even to own and maintain your own physical servers, because you're interested in writing web applications. You should maybe consider taking the same approach to authentication.

      EDIT: I may have misunderstood - if by "calling API routes" you actually mean interacting with one of these third party authentication providers, then my advice is totally redundant. Even so, I can't imagine any authentication provider (or their API, or the module they provide to integrate their service into your app) sending anything in the clear. The whole idea is that they take responsibility for the users secrets. Their job is to make using their service as easy and secure as possible for you and your users.

        Start asking to get answers

        Find the answer to your question by asking.

        Ask question

        Explore related questions

        See similar questions with these tags.