1

I have been following this tutorial on how to create JWT authorization in an asp.net Web API application.

In my case the authentication server will be the same server holding the resources (ie all done in the one asp.net Web API application), so I can see that sharing the "secret" used in encoding the JWT is not a problem when it come to the route authentication and authorization.

However, I will have have an Mobile application (using the Ionic framework) where I would like to be able to validate and decode the JWT so that I can enable/disable different parts of the UI. So I will need to do this in JavaScript.

So, I would not want the application to have access to this "secret" string used to encode the JWT.

My questions are

  1. How can I both validate and decode a JWT without having to have this "secret" key?

  2. Reading other posts, perhaps the validation is not possible, but decoding is. In this case there is the possibility of incorrect UI enabling, but in the end the web API call will fails as this can do the validation as well. Is this the correct way to go about it

  3. Is there another way of creating the JWT where we have private and public key, so the JavaScript can have the public key and use this for the validation?

Thanks in advance for any help!

peterc
  • 6,921
  • 9
  • 65
  • 131

1 Answers1

1

You can use signing algorithms like RS256 that are based on asymmetric cryptography. This means that signing a token requires access to a private key, which can be safely stored server-side, and validating requires only access to a public key.

JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with HMAC algorithm) or a public/private key pair using RSA.

(source: Learn JSON Web Tokens; emphasis is mine)

As you mentioned, the decisions you make on the client application running on a user device should only be done from a user experience perspective and all authorization decisions should still be done again on the server-side.

The best analogy is the Javascript form validation that can be done on the browser to provide the user with instant feedback but that still requires the same or even greater validation to be done on the server-side as an attacker could easily bypass the client-side ones.

Additionally, you should take in consideration:

  • This interpretation of a token by a client application despite the fact that the token is intended for use in the API is acceptable if you're okay with having a really tight relationship between the client application and the resource server. From your description, all the parts of the system are under your control so this seems fine.
  • The use of RSA256 has associated performance costs when compared with the use of HS256 which is based on the shared secret you mentioned. If this is an issue you can even question yourself if you really need to validate the token client-side; if all the decisions you make are purely cosmetic why bother with the validation. The premise would be that someone trying to provide a fake token would only see options or links that would immediately fail when accessed due to the server-side rejecting the token
João Angelo
  • 56,552
  • 12
  • 145
  • 147
  • Thank you for that in depth answer. That all makes sense. Reading that I am thinking perhaps no client side validation, just decoding which looks like can be done as explained [here](http://stackoverflow.com/questions/38552003/how-to-decode-jwt-token-in-javascript) so can use the cheaper validation server side, as this will be done every request. – peterc Dec 07 '16 at 12:40