Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

There are server side JWTs that are never exposed to the users.


I thought the entire point of signing a JWT was because you need to validate it because there is some endpoint that is untrusted and you have to treat the claims as potentially compromised.


Yes? And?

I may have a backend service that is both internally and externally exposed, necessitating all requests to it be signed. I may have a backend service that has load limits that need to be fairly adhered to, and to do that I allow users only so many requests per time period. Even without load limits, I may want to know who is calling me, and forcing services to first request a token on behalf of themselves makes it more likely that each service will uniquely identify itself.

Really, if you trust the callers of your API enough to allow unsigned JWTs, you probably should trust them enough to not require anything (because copy/paste mistakes alone mean the data isn't valid, intention aside). If you can think of a reason why not having any identity information at all is problematic, you should probably force a signed JWT. The extra effort is negligible, it reduces potential risk if the use of the service changes and it starts getting 'untrusted' users, and it helps reduce "oops" mistakes upfront.


JWTs are in end like passwords.

Sure they have a limited duration.

Sure they might not work for all actions.

Sure they don't need a password database on the side of the receiver.

But it's best to treat them like temporary password + some arbitrary metadata.

So no, they don't protect you from corrupted clients, they just limit the damage in what can happen and when it can happen but the corrupt client can still do all kinds of bad things.

Edit: I need a different Android keyboard, this is driving me nuts.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: