Open unbalancedparentheses opened 7 years ago
We should look into it. I don't think jwt adds much complexity, but haven't really thought what advantage it has as opposed to another kind of token auth. The good thing of token auth in general is that it let's us generate a token at login and then use it to access the rest of the API without sending credentials again. So if we want to, for example, support both user/password auth and google login, then we only need to change the login handler, the rest will work the same.
I haven't really read a lot but I think HMAC doesn't work for our case, since it needs both sides to know the secret, in our case the password; that would mean the server would have to store the password instead of the password hash in the db. See here: http://blog.restcase.com/restful-api-authentication-basics/#hmac
The server can generate the digest as well, since it has all information. Please note that the "password" is not encrypted on the server, as the server needs to know the actual value. This is why te name "secret" is preffered and not a "password".
Plus it has the same downside as basic auth, if we want to add a different auth method (like google login), we need to support both on every api endpoint.
I'd lean towards sticking with jwt unless we identify some disadvantage it has for our use case; on a quick review of the links I'm not sure most of them apply for us, I'll read with more detail during the week.
I think JWT is way too compliated and specially for something as simple. Let's read and discuss other solutions: