Just a heads-up: the font-weight of your lead paragraph makes it too light on Chrome+Windows, some of the diagonals pretty much disappear.
JSON Web Tokens
11–20 of 76 posts
Re: JSON Web Tokens
#12Shameless plug, but just gave a JWT talk at DjangoCon this week. https://speakerdeck.com/jpadilla/djangocon-json-web-tokens
Is there a video of your talk available?
Re: JSON Web Tokens
#13For an angular js implementation with server examples:
https://github.com/sahat/satellizer
It's still a very new project, but looks promising.
Re: JSON Web Tokens
#14What's the Auth0 Java JWT library like?
I've been using the Google library[1], in a dropwizard app and it's pretty old and not great.
OTOH, I do recommend both Dropwizard (the OAuth stuff lets JWT drop straight in) and Satellizer[2] for Angular.JS JWT stuff.
Re: JSON Web Tokens
#15I think writing your own variation of this at one point is a sort of rite of passage for web developers. I thought I was so clever with my custom PHP framework and sessionless backend. That said, it's done because it works well and makes sense. I'm glad to see we're finally settling on a recommended way of doing this.
I've recently incorporated JWTs into my own application. One of the questions I'd like to ask other HNers is how you deal with token expiration. I don't want to reissue a token if I don't have to, but I don't want to create permanent tokens either. An obvious solution is to embed an expiry in the token and check against that, however I don't think that'll lead to a very good UX if tokens "randomly" expire. I've come up with two solutions: 1.) Each user has a session seed token that is used as the secret and thus a user can log out of all sessions by requesting a secret change. This works because any previous JWTs are now invalid because they cannot be validated with the new secret. 2.) I could ping the server periodically (or decode the JWT on the client side) and check when the token expires. Shortly before the token expires, I could request a new one. This doesn't solve the problem of tokens expiring when the user is offline though. Anyone have any better solutions?
Re: JSON Web Tokens
#16This 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.
Re: JSON Web Tokens
#17This 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 val…
The 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) 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!
Re: JSON Web Tokens
#18I think writing your own variation of this at one point is a sort of rite of passage for web developers. I thought I was so clever with my custom PHP framework and sessionless backend. That said, it's done because it works well and makes sense. I'm glad to see we're finally settling on a recommended way of doing this. I've recently incorporated JWTs into my own application. One of the questions I'd like to ask other…
The OAuth way of doing things is to have two tokens: an auth token and a refresh token. The auth token is the one you send with your requests to authenticate them (and can be a JWT), but it has a very short expiry time (say an hour). The refresh token is typically a random string that's stored in your database and can be used in place of a username/password or other credentials to get an auth token.
This way you can store (in an app, or a browser) the less sensitive refresh token (which might expire after a week or so) instead of the highly sensitive permanent auth credentials.
Re: JSON Web Tokens
#19How do you invalidate tokens?
Re: JSON Web Tokens
#20Shameless plug, but just gave a JWT talk at DjangoCon this week. https://speakerdeck.com/jpadilla/djangocon-json-web-tokens
Is there a video of your talk available?
I can't answer your question specifically, but confreaks.com has an event page for DjangoCon, so hopefully it will pop up on there.