4 ms·

Nonsense. Issues like inability to revoke JWTs don't apply to bearer tokens where the API server needs to query the token issuer to found out who the user is (w

Nonsense. Issues like inability to revoke JWTs don't apply to bearer tokens where the API server needs to query the token issuer to found out who the user is (which can then implment revoking the token simply by dropping the record for the token from the DB, all further calls will fail the lookup!) Remember they stated: > Major advantage of JWT compared to bearer tokens [...] is that they don't require looking up the token. Other problems with JWTs vs opaque bearer tokens they listed include: - increased attack surface due to complexity of JSON parsing/validation - misconfiguring JWT libraries to allow no signature - leaking data to users because you thought JWTs were encrypted Now you are right that some of the complexities involved with JWTs like refresh token can apply with arbitrary bearer tokens, especially if you want to limit the lifespan of the access token, but those are implementation choices. Technically you can just have a single long lived bearer token instead of a long lived refresh token, and a short lived access token.

feoren 4y ago
Hold on, this is backward. They said: > You should not use Thing X because the advantage it has over Thing Y is not an advantage. In fact both Thing X and Thing Y have the same disadvantage. Except that Thing X has a workaround and Thing Y doesn't. But that workaround adds (gasp!) complexity! Obviously, we only ever use Thing Y and you're a bad developer if you use Thing X. It's smoke and mirrors. They never give an advantage of bearer tokens over, well, JWT barer tokens, which are a type of bearer token, the thing they said they use. They just said JWTs don't actually have one specific advantage, except when they do. That's not an argument against JWTs! > increased attack surface due to complexity of JSON parsing/validation People who use JWTs are already parsing JSON everywhere. It's not hard. If it's not valid JSON, clearly you don't authenticate. > misconfiguring JWT libraries to allow no signature You can misconfigure anything. You can misconfigure your server to not actually check the bearer token. Why is it more likely you'll forget to check the JWT signature than the bearer token? This is something you write one time and never touch; it takes an afternoon at most. > leaking data to users because you thought JWTs were encrypted Yes, you should not put sensitive data in a JWT, encrypted or not. This is a fair criticism. > Technically you can just have a single long lived bearer token instead of a long lived refresh token, and a short lived access token. Which, as they pointed out in that article, is a disadvantage of long-lived bearer tokens.

feoren 4y ago

Hold on, this is backward. They said: > You should not use Thing X because the advantage it has over Thing Y is not an advantage. In fact both Thing X and Thing Y have the same disadvantage. Except that Thing X has a workaround and Thing Y doesn't. But that workaround adds (gasp!) complexity! Obviously, we only ever use Thing Y and you're a bad developer if you use Thing X. It's smoke and mirrors. They never give an advantage of bearer tokens over, well, JWT barer tokens, which are a type of bearer token, the thing they said they use. They just said JWTs don't actually have one specific advantage, except when they do. That's not an argument against JWTs! > increased attack surface due to complexity of JSON parsing/validation People who use JWTs are already parsing JSON everywhere. It's not hard. If it's not valid JSON, clearly you don't authenticate. > misconfiguring JWT libraries to allow no signature You can misconfigure anything. You can misconfigure your server to not actually check the bearer token. Why is it more likely you'll forget to check the JWT signature than the bearer token? This is something you write one time and never touch; it takes an afternoon at most. > leaking data to users because you thought JWTs were encrypted Yes, you should not put sensitive data in a JWT, encrypted or not. This is a fair criticism. > Technically you can just have a single long lived bearer token instead of a long lived refresh token, and a short lived access token. Which, as they pointed out in that article, is a disadvantage of long-lived bearer tokens.