3 ms·
This is a pretty elegant solution for delegated authority, too. If you have client-side code as well as server-side code that both access an API, JWTs can give
by Todd 12y ago
This is a pretty elegant solution for delegated authority, too. If you have client-side code as well as server-side code that both access an API, JWTs can give you a uniform way of handling authorization at the API level.
Client side access is pretty well understood. A JWT can be stored in a cookie and then added to Ajax requests as a bearer token, for example.
The server-side code will typically have some way of validating the client, such as an encoded cookie. This will be used to build a user object of some sort, which can be used to run authorization checks. When the server side needs to access the API, the user object can be serialized into a JWT and added as a request header, similar to typical client-side access. If it's done well, the API can use a very similar user object to check authorization. Another option is just to do JWT pass-through. If this is done, the signature should at least be checked to avoid facilitating an impersonation attack.
JWTs have built in signing to ensure that the user object is intact. All that is left is to encrypt the channel with SSL.
- iLoch 12y agoThe pattern I've seen used most commonly is the latter situation you described. The user authenticates, and is issued a signed JWT which includes their user ID and (optionally - I actually talk about this in my comment here: https://news.ycombinator.com/item?id=8283530 https://news.ycombinator.com/item?id=8283530) an expiration. You can also delegate roles and permissions through the JWT, which makes for a really slick authorization pattern if you've got a case where you'd like to easily change a user's permissions. I mean, you can add whatever you want to a JWT - I guess I'm just offering suggestions based on my own experience. IMO, user ID is the best way to go, because it's only a single field you have to maintain. If you start adding too much information in there you might end up with a bunch of tokens with old property names etc. Personally I just tried to closely follow what OAuth specified should be added to OAuth JWTs. I think I've got "issuer", "audience", "expiry" and "id" in my current tokens, but adding a list of permissions would be a good choice too in my opinion. I think what everyone needs to remember is that SSL is a must for these things. If you're issuing non-expiring tokens over non-SSL you're just giving the keys to the castle away. Another thing that should be considered is token storage. I'm using local storage right now which works for me, but it just means I need to be more careful than ever about XSS exploits, because there's no "HTTP only" option for local storage!