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

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 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!