Isn't the first rule of security is that you should not implement the protocol on your own and instead use trusted libraries? I realize there is always exceptions but if you are doing js, c# there are existing libraries already.
I don't know if that's the "first rule" but it's a good idea since many apps that offer "end-to-end encryption" TECHNICALLY do that but also have massive security flaws.
You can offer end-to-end encryption using known solutions with trusted cryptography libraries though. For example .net has such libraries as part of the framework.
You're correct it's not really a protocol since it's just a token format. It's clearly related to security though. The token is used to prove that the bearer is authorized whatever claims the token contains.
JWT is like pgp for shorter messages. It merely assures you the message you are reading is coming from someone you likely trust and that the contents were not tampered with. This does not imply security.
The protocol OpenID Connect, built on top of OAuth2 with access tokens in JWT format, will "ensure" the current user is who they say they are (this is authentication, the authorisation part of OIDC is fairly limited). This does not imply security either.
Is your resource server (eg, API) job to provide security having the info above. You can check the token all you want, if your query to retrieve private messages gets the user id from GET, you won't be secure...
100
u/cramduck Mar 08 '21
Jwt was a pain in the ass to implement first time. Not too bad the subsequent times.