What I've gathered from this post is that the tech community ought to spend more time promoting JWT best practices because misuse can lead to bad times
JSON Web Tokens should be avoided
51–60 of 304 posts
Re: JSON Web Tokens should be avoided
#52I use stateful JWTs for session management, storing them in localStorage. If someone can exfiltrate the token, they will get a week long authorization, as well as some identifiable information (username, name and role). Probably I can achieve the same overall system with cryptographically secure session cookies, that are persisted in a database, or other store that is accessible across multiple servers. I guess it wo…
If I can offer some advice in the other direction, don't use cookies. I tried to do the right thing, use HTTP-only cookies set over an HTTPS endpoint only to find that it's stupidly complicated and has a lot of annoying edge cases. Turns out iOS's webviews don't like them, iOS in general doesn't like them to be on api.hostname.com if the app is on app.hostname.com, you can't validate if you are logged in or not witho…
Ideally you need to use httpOnly cookies to store your JWTs too.
Re: JSON Web Tokens should be avoided
#53Lock the encryption to RS512 and the standard is fine. I do a test against that and I also include a key relevant to and content I send with the token. This make the signature per request and considerably more difficult to forge. Maybe using JWTs for sessions is bad, using them for APIs is awesome with the specific caveats.
Re: JSON Web Tokens should be avoided
#54Should we use Hawk + Oz[1]?
[1] https://hueniverse.com/2015/09/19/auth-to-see-the-wizard-or-...
Re: JSON Web Tokens should be avoided
#55Is using none a bit like using http instead of https? The standards support it, but it's 2017 so we shouldn't do it.
What I like about JWT's concept is it's completely distributed authorisation: there's no call to a central identity provider. Thus a SPA can pull initial security info from its server, and then fire out requests to different APIs. As long as the API endpoints have the SPA server's public key, they can verify everything without calling it or another central server.
Having said that, I'm not able to discern whether it's secure enough to be workable, so I only know to mandate a list of good algorithms on the API endpoints and to use SSL :) I'll have to read about this session stuff.
EDIT: I wonder if in bigger projects, a message bus or in-memory cache could signal a token blacklist once the user logs/times out of the original server? Or as some others have said, just have short expiry times and ping the SPA server for new tokens every couple of minutes.
Re: JSON Web Tokens should be avoided
#56I use stateful JWTs for session management, storing them in localStorage. If someone can exfiltrate the token, they will get a week long authorization, as well as some identifiable information (username, name and role). Probably I can achieve the same overall system with cryptographically secure session cookies, that are persisted in a database, or other store that is accessible across multiple servers. I guess it wo…
If I can offer some advice in the other direction, don't use cookies. I tried to do the right thing, use HTTP-only cookies set over an HTTPS endpoint only to find that it's stupidly complicated and has a lot of annoying edge cases. Turns out iOS's webviews don't like them, iOS in general doesn't like them to be on api.hostname.com if the app is on app.hostname.com, you can't validate if you are logged in or not witho…
Wouldn't you need to assign your cookies to the TLD for them to be accessible to both subdomains?
Re: JSON Web Tokens should be avoided
#57The "none" algorithm set in header is a well known problem and, for example, nodejs most used library automatically uses asymmetric keys when one is given, ignoring the header ( https://github.com/auth0/node-jsonwebtoken/blob/master/verif... ) As long as the problem is known to the developers and the key is specified, I think the biggest issue of JWT is the lack of session invalidation (that is, if you log out your a…
Session invalid is an issue with all Tokens.
Re: JSON Web Tokens should be avoided
#58Earlier quoted context omitted.
If I can offer some advice in the other direction, don't use cookies. I tried to do the right thing, use HTTP-only cookies set over an HTTPS endpoint only to find that it's stupidly complicated and has a lot of annoying edge cases. Turns out iOS's webviews don't like them, iOS in general doesn't like them to be on api.hostname.com if the app is on app.hostname.com, you can't validate if you are logged in or not witho…
Wouldn't you need to assign your cookies to the TLD for them to be accessible to both subdomains?
We only wanted them assigned to the subdomain that needed them (api.hostname.com), and we set it up that way to make sure we wouldn't accidentally expose cookies to other domains down the line.
Re: JSON Web Tokens should be avoided
#59I use stateful JWTs for session management, storing them in localStorage. If someone can exfiltrate the token, they will get a week long authorization, as well as some identifiable information (username, name and role). Probably I can achieve the same overall system with cryptographically secure session cookies, that are persisted in a database, or other store that is accessible across multiple servers. I guess it wo…
If I can offer some advice in the other direction, don't use cookies. I tried to do the right thing, use HTTP-only cookies set over an HTTPS endpoint only to find that it's stupidly complicated and has a lot of annoying edge cases. Turns out iOS's webviews don't like them, iOS in general doesn't like them to be on api.hostname.com if the app is on app.hostname.com, you can't validate if you are logged in or not witho…
When you say validate login in a react app, what do you mean? Surely the only way to validate a login is to make a request. Or are you saying that your tokens never expire?
Re: JSON Web Tokens should be avoided
#60Earlier quoted context omitted.
If I can offer some advice in the other direction, don't use cookies. I tried to do the right thing, use HTTP-only cookies set over an HTTPS endpoint only to find that it's stupidly complicated and has a lot of annoying edge cases. Turns out iOS's webviews don't like them, iOS in general doesn't like them to be on api.hostname.com if the app is on app.hostname.com, you can't validate if you are logged in or not witho…
When you say validate login in a react app, what do you mean? Surely the only way to validate a login is to make a request. Or are you saying that your tokens never expire?
Not really validate, just maintain state. (probably should have worded that better...)
Of course the server is going to validate it every request, but it's nicer being able to fail "sooner" on the client side when we know we aren't signed in, or we have never signed in, or our token expired a day ago and we need to re-login, etc...
With HTTPOnly cookies we need to make a request to find any of that out, and when paired with redux and react it's very annoying to have to make a web request to get a small glimpse into what the state really is and try and maintain that in a JS value somewhere AND avoid flashes of incorrect state.
Hell with HTTPOnly cookies you can't even clear it without a web request!