OT but I need a wake-up call here. Upon login I'm sending back a generated UUID tied to the account and saves it as a cookie in the client. What's wrong with this approach?
JSON Web Tokens should be avoided
101–110 of 304 posts
Re: JSON Web Tokens should be avoided
#102The criticisms of JWT seem to fall into two categories: (1) Criticizing vulnerabilities in particular JWT libraries, as in this article. (2) Generally criticizing the practice of using any "stateless" client tokens. Because there's no great way to revoke them early while remaining stateless, etc. The problem is that both of these groups only criticize, neither of them can ever seem to actually recommend any alternati…
> If I'm providing a REST API, then I'd prefer a token string that I could pass as a header value rather than forcing the use of cookies
Aren't cookies just strings passed as HTTP headers?
Re: JSON Web Tokens should be avoided
#103The criticisms of JWT seem to fall into two categories: (1) Criticizing vulnerabilities in particular JWT libraries, as in this article. (2) Generally criticizing the practice of using any "stateless" client tokens. Because there's no great way to revoke them early while remaining stateless, etc. The problem is that both of these groups only criticize, neither of them can ever seem to actually recommend any alternati…
> If I'm providing a REST API, then I'd prefer a token string that I could pass as a header value rather than forcing the use of cookies Aren't cookies just strings passed as HTTP headers?
I hope someone can explain to me in practical terms difference between a session cookie string on a request and a token as header value.
Re: JSON Web Tokens should be avoided
#104The criticisms of JWT seem to fall into two categories: (1) Criticizing vulnerabilities in particular JWT libraries, as in this article. (2) Generally criticizing the practice of using any "stateless" client tokens. Because there's no great way to revoke them early while remaining stateless, etc. The problem is that both of these groups only criticize, neither of them can ever seem to actually recommend any alternati…
The article very clearly is about the standard, not a particular JWT library.
Server-side session tokens stored in the database worked fine ten years ago, and they work fine today. No need to muck with the load balancer.
Stateless tokens are great too, and use two-factor auth when you need that extra layer of security. No need for newfangled standards; HTTP Basic remains a simple and effective way to convey that token.
Re: JSON Web Tokens should be avoided
#105I 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…
well you can use JWT + Cookies...
JWT request to https://api.somewhere.com/token-signin to get cookies for https://api.somewhere.com
(of course you 'can' but I'm not sure if this is recommended or not.)
Re: JSON Web Tokens should be avoided
#106Title misleading: JSON Web tokens should be avoided
Re: JSON Web Tokens should be avoided
#107One advantage I think not mentioned by some of the linked articles is that the JWT's claims are readable on the client. It's a pretty good plus, for me: no additional round-trips to the server to grab key user details, which can be put into claims, or check access levels (via roles, permissions, or other types of claim). This doesn't discount the disadvantages, of course.. I think as with everything it's a case of th…
You've already been to the server once, if you terri-bad app design requires you to go twice that's more your problem than a "feature" of a broken session system.
Fine, then - to rephrase, it conveniently combines claims with an assertion that the user has been authenticated and authorised. You can do it in other ways too, but it's convenient and a designed part of the make-up of JWT.
Re: JSON Web Tokens should be avoided
#108The criticisms of JWT seem to fall into two categories: (1) Criticizing vulnerabilities in particular JWT libraries, as in this article. (2) Generally criticizing the practice of using any "stateless" client tokens. Because there's no great way to revoke them early while remaining stateless, etc. The problem is that both of these groups only criticize, neither of them can ever seem to actually recommend any alternati…
Either way, if you're serving up a REST API to a JavaScript UI... what's NOT a good option is server-side session state (e.g. Java servlet sessions) Can you explain what you mean, as oppose to other kinds of session tokens? Roy Fielding makes it abundantly clear[0] in the seminal delineation of REST that We next add a constraint to the client-server interaction: communication must be stateless in nature, as in the cl…
IMO sessions for authentication is fine as long as we don't store any session variables. In the end someone's going to be keeping track of the number of GET requests made by each API consumer on each endpoint, and practically it's not breaking REST as long as that state doesn't affect the information GETable by the client.
Re: JSON Web Tokens should be avoided
#109Earlier quoted context omitted.
I feel like the argument against #2 is usually purely hypothetical in nature. I really do not have a problem maintaining a small lookup cache for revocations. I feel like the argument against doing this tries to take the form of all server-side kept state is bad when in reality it's sticky state and huge object graphs (read: memory consumption) that get stuffed into session objects that are the real evil. A server wi…
Sure, revocation lists are relatively small. But they need to be available to every server (replication), be proof against server/service restarts (durable), and checked with every request (highly performant). So, a good revocation list effectively requires a database. Not a trivial thing to implement yourself, and a weighty requirement for an otherwise stateless service.
Hmmm, using a database (eg PG) for the authoritative information, with memcached in front sounds like it would be practical for most uses.
Re: JSON Web Tokens should be avoided
#110Earlier quoted context omitted.
> If I'm providing a REST API, then I'd prefer a token string that I could pass as a header value rather than forcing the use of cookies Aren't cookies just strings passed as HTTP headers?
I hope someone can explain to me in practical terms difference between a session cookie string on a request and a token as header value.
Cookies are just string in a header. The difference is that unlike normal headers browesers treat cookie headers in a special way. They automatically add and remove keys from it, and they allow the server to set the header in a way that the client can neither see it nor change it (http only headers)