What advantage does signing a JWT with RSA have over SHA in the contect of a RESTful API?

user_5881804 0
Viewed 1400

I have a backend which exposes a RESTful API which is currently 'free for all' (but uses https).

I now want to add RBAC (role-based access control) and JWT seems the way to go and I read a lot about JWT, but don't see the advantage of using RSA over SHA to sign the token.

Assumption is that the user has authenticated and obtained a key, be it shared or public/private.

Now, it seems to me that in both cases - SHA or RSA HMAC - both parties (client and server) must have the shared key, or their half of the private/public key in the case of RSA. And the server must find that key (in a table or database) based on a claim in the JWT in order to verify the token's signature. Once it has confirmed the purported user in the JWT it will then authorise the request using the configured roles.

So what are the advantages of RSA in that scenario ?

jwt hmac sha rsa rest
2 Answers

I assume you're talking about RSxxx (e.g. RSA256) and HSxxx (e.g. HS256 (HMAC-SHA256)) algorithms here. The main difference is that HS256 is an symmetric algorithm while RS256 is an asymmetric algorithm. Symmetric algorithms just use one key (or secret) for signing and verifying, whereas asymmetric algorithms use the private key to sign and the public key to verify the token.

If you share the secret used for HS256, everyone knowing the secret could issue or modify and re-sign a token. That would defeat the purpose of the signature if you share the secret with the client. In case of RS256 or any other asymmetric algorithm, only the authentication server knows the private key and anyone who need to verify the token can use the public key to do so. The matching key is usually identified by the KID (Key Id) claim in the header of the token.

But usually, signing and verifying is only done on server side, the client does not need to verify the token and thus does not need to know the key or secret at all. Therefore you can in case of a simple service, when authentication and resource server are the same, still rely on a symmetric algorithms. But once you have one separate authentication server for several resource servers, asymmetric algotrithms should be used.

user_73298320

Thanks for the response, that does help make it clearer.

So basically, for a simple RESTful API, there is no real advantage using RSA over HSA.

Some points that may help others about token-based authentication:

Preamble: the following are all in the context of using SSL.

Firstly, a token is a substitute for username/password credentials: if a client has a token, it is equivalent to having username/password. It took me a while to figure that out. A bit like using a badge at a corporate printer: instead of entering username and password you just place your badge (the token) on the printer and it knows who you are and prints your document.

However, tokens make using an API much simpler because

  • the client simply adds its token to the http header,
  • the server only verifies the token,
  • neither have to deal with authentication flows involving username/pw and managing session cookies.

But the downsides are that

  • losing the token is like losing the username/password, and
  • in a complex system involving many components, tokens would have to be shared across all involved backend servers.

Secondly, the client doesn't strictly need to verify the token - it only needs the token - if someone gives you a key to their house or car, you don't typically check the key, you trust the person (maybe sometimes foolishly so) and use it. So a simple random string can serve as a token; the server maintains a simple table correlating tokens to users, no keys involved at all. If a client sends a token that the server doesn't have --> access denied. If it has a matching token --> look up the user that correlates to the token (typically followed by authorisation).

Thirdly, the server typically generates a token either based on trusting the client, or after the client has somehow authenticated, e.g . oauth. Afterwards, the client just sends the token with every request and the server looks it up in its table. However, such server-side tables for random-string tokens may become large and have to be persistent, so either a database or a file is required, and they are typically comparably slow, require maintenance etc, so enter using cryptographic signatures and jwt:

Fourthly, tokens with signature:

  • the server signs the token and sends it to the client - but the server does not have to store it, also no session cookies as described above
  • the client stores the token securely and sends it with every subsequent request (just like with a random string token)
  • the server receives the request, calculates the signature of the jwt, and compares it with the signature of the token sent by the client. Note that there is no file or DB lookup, only computing the signature again and comparing it with the signature sent by the client. If the signatures match then the token must be the same as the one the server issued and hence the jwt header and payload are also the same as issued by the server
  • the server now interprets the payload, esp. the user (and typically performs authorisation)

So, using jwt means the server does NOT need

  • a database or file with user names and tokens
  • to save tokens
  • to maintain session cookies

It only needs to create and compare a signature. And for that it needs a cryptographic key. This can be a symmetric key for a simple API or an asymmetric key for more complex systems where public keys must be shared.

Hope this helps some other tortured souls who grappled with this topic.

user_58818040
Related