0

My question is specifically regarding my approach of JWT with REST implementation.

I am using AngularJS on the client side and PHP on server side.

As soon as page loads for the first time, I fire one GET request to server and get signature from web service (encoded signature).

When someone opens the web page, we present login form and when user fills it correctly, we send login information to server in JWT encrypted format:

Header(ALGORITHM & TOKEN TYPE).Payload(Login form data).Signature(Received from the first GET web service call)

Now, after login, we got the exp i.e. token expire time out data from server. Now we show one more form to the logged in user. It is used to create employees. So, my implementation is:

  • We present the form (using angularjs)
  • User inputs the data
  • System validates the form
  • If the form entries are correct then system triggers addEmployee webservice. BUT the data we pass in header authorization bearer only. For example:

Host: mysite.com POST: /services/addEmployee Accept: application/json Content-Type: application/json Authorization: Bearer Header(ALGORITHM & TOKEN TYPE).PAYLOAD(Employee form data + EXP token expire time received in the response of login web service).Signature

So, here we don't pass anything on the request body. Even though this is being POST request. And on the server side, we just decode the Bearer and get the payload.

I really don't want to send any data in plain text format. For example, if we send POST data in body then anyone can see what's being passed. I want to encrypt my web services up to some level. Is this approach correct or harmful in anyway?

Ravi Maniyar
  • 661
  • 2
  • 7
  • 22
  • 2
    Why not use https? – Robert Moskal Jul 01 '16 at 04:16
  • JWT only works over HTTPS. Well, any static cookie-based session scheme only works over HTTPS. – MK. Jul 01 '16 at 04:25
  • @MK. JWT works with both HTTP and HTTPS. – Ravi Maniyar Jul 02 '16 at 03:08
  • @RobertMoskal Check out this [answer](http://stackoverflow.com/questions/3976728/how-to-configure-ssl-certificates-with-charles-web-proxy-and-the-latest-android) - using Charles anyone can debug HTTPS request very easily. – Ravi Maniyar Jul 02 '16 at 03:08
  • My question is related specifically to headers. Is it really fine to send all the payload and signature data into `Header Authorization: Bearer ` format, and leave the request body totally blank? – Ravi Maniyar Jul 02 '16 at 03:09
  • @RaviManiyar depends on your definition of working. not secure. – MK. Jul 02 '16 at 03:10
  • @MK. Thanks for getting back to me. Can please you let me know even if its encoded, why its not secure? – Ravi Maniyar Jul 02 '16 at 03:11
  • because if it is not encrypted attacker can intercept it and send his request with the same JWT. – MK. Jul 02 '16 at 04:50
  • 1
    @MK., no its encrypted, see my above comments. The header authorization goes like this: `Header Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ` – Ravi Maniyar Jul 02 '16 at 14:27
  • it is not encrypted, it is signed and encoded. I can't create my own JWTs because I don't have the key you signed it with, but I can send requests with your JWTs if I can intercept them. – MK. Jul 02 '16 at 15:57
  • @MK. That makes sense. Thanks. Can you please let me know how to ENCRYPT the JWT? I can't seem to find that in the official documentation. – Ravi Maniyar Jul 07 '16 at 18:39
  • You don't encrypt the JWT. That's not the point of it. JWT proves your identity (and perhaps your rights) using a signature. Encryption is done by https. – MK. Jul 08 '16 at 02:12
  • @MK. Got it. Thanks man. Please post this as the answer and I will accept it and then we can close this thread. – Ravi Maniyar Jul 10 '16 at 18:17

1 Answers1

0

I think your approach is wrong. The JWT payload is not intented to hold sensitive information. Anyone can read it. You could encript the payload, however it's not the way JWT are usually used for.

Usually a JWT payload should contain claims that are not sensitive or request-specific (such your employees form data). Keep that data in the request body, so you can reuse the JWT for different API calls no matter what HTTP verb and params you use for your different needs.

The entire request will be encripted with SSL so you're not sending any plain text data. Never use this without HTTPS, as anybody could get your token and impersonate the user.

Hope it helps, regards.

Alberto
  • 31
  • 4