14 ms·

JWT should not be your default for sessions

335 points by mfbx9da4 5y ago

bluefirebrand 5y ago
> If they’re not safe, what chance does the general (developer) public have? Something I've been wondering is, do we really have any evidence that the average Auth0 developer is more of a security expert than any other dev? I'm sure they have security experts on staff designing systems but it doesn't seem likely that everyone doing the building is an expert. They are as likely as any to code in mistakes
- goalieca 5y ago
  > Something I've been wondering is, do we really have any evidence that the average Auth0 developer is more of a security expert than any other dev? Security companies have average developers just like everyone else. They probably do have better domain knowledge from working on their product but they will miss other important things. The real difference in security comes from product management. Almost everyone I've talked to has some sort of risk assessment process where these sorts of things are laid down in great detail. The leading companies will invest in not only trying to discover weaknesses but will plan to mitigate or resolve the issues within a reasonable timeline.
rsj_hn 5y ago
JWTs are good for API tokens, not end users. If you use JWTs for your cookies/session state, then you'll still need to maintain a table of valid JWTs and expire them when the user logs out, and thus you will not be able to use JWTs as they were intended to be used, which is as stateless tokens. Most security auditors/certifications/compliance requirements do not consider even a 5 minute lag acceptable for user driven logout. The definition of logout is that when the user presses the logout button, all the session data is invalidated server-side during roughly the time it takes for a request/response roundtrip. Thus there is no benefit to using a non-opaque high entropy string for user sessions, even though there is a good benefit to using JWTs as API tokens for back-end services (esp. microservices) that do not have browser logout requirements.
- aflag 5y ago
  Why can't you just delete the cookie when the user logs out?
  - jakereps 5y ago
    That token itself is still valid - regardless of whether or not their browser still has it stored.
  - hermanradtke 5y ago
    The issue is not deleting the cookie. The issue is that the JWT can still be used as a valid session unless you have some sort of blocklist. Once you introduce a blocklist, you might as well ditch the JWT and use some opaque token stored in a table.
    - axiosgunnar 5y ago
      the entire article could be summed up with this post tbh
    - remram 5y ago
      Is that a problem though? Does your threat model include clients that correctly send logout requests when they're supposed to but don't delete cookies when they're told?
      - colinclerk 5y ago
        Your application should certainly have some resolution to an account being hacked or a session token being stolen. No expiry and no denylist means an attacker can cause problems until you patch your code.
      - SigmundA 5y ago
        Never trust the client, ever.
        5y ago
frompdx 5y ago
The author says one of the selling points of JWT is scale, and points out many will not need to concern themselves with scale and to stick with simple solutions. But I am curious to know if any on HN is using session cookies at scale and how they solve the scalability issues of session cookies alluded to in the article?
- nkozyra 5y ago
  I think the whole "sessions don't scale" predates an era of cheap, shardable/distributable and performant options from NoSQL to RDBMS. It used to be a serious bottleneck for even smaller sites. But they also used to stick them in stodgy, table-locking storage engines in the same database as the rest of their application. Times have changed and I really believe you can manage cookies<->sessions without too much overhead. And if you're willing to let a JWT have a 5-minute max life, you could similarly cache your session responses for 5 minutes. Like all things, there comes a tipping point eventually. But it's not as early or as drastic as it once was.
- echelon 5y ago
  I've been heavily involved in an active-active session service that handles 100kqps+. It's not that hard to achieve with Redis. If you model your sessions as an acyclical state machine, you can quickly consolidate a single view of all sessions globally. Beyond this, it's valuable to be able to scope sessions, invalidate subsets of sessions, create delegate sessions, provide an audit trail for internal support staff using session impersonation, etc. JWTs can't give you a lot of the rich security behaviors that real sessions can, such as asking a user to use 2FA for editing sensitive data if they haven't provided that information in the last 15 minutes. Or estimate user idle time.
  - jruthers 5y ago
    Would you be able to expand on scoped sessions, invalidated subsets, delegated sessions? Our roadmap has a big emphasis on improved session management and these are ideas we haven't considered and I'm keen to understand more.
porphyra 5y ago
Why is "JWT" not defined or explained until I scroll a few pages down and find one that's hyperlinked? I thought it was talking about the James Webb Telescope this whole time.
- CraftThatBlock 5y ago
  "JWT" is a pretty popular term. The James Webb telescope is the JWST (space being the S)
- treve 5y ago
  The first one is hyperlinked, unless you count the title.
VincentEvans 5y ago
I think you are overlooking the main benefit of JWT - is to allow authentication by a trusted third party, thus enabling single sign on, eliminating the need for password storage and management, login forms, etcetera.
- layoutIfNeeded 5y ago
  You’ve failed to understand the article. Please don’t write backend software.
- yashap 5y ago
  Not sure why you’re being downvoted, but agreed. Tonnes of apps want to support SSO, and most modern SSO systems use Open ID Connect, where the id tokens are JWTs. If you want to let your users login via Google, Facebook, Okta, whatever, then you’ll be dealing JWTs. And once you’re doing that, it’s a small step to say: “even if my users want to signup/login via username and password, I’d rather not manage that myself. I’d rather use a 3rd party system to store the passwords, implement MFA and password recovery and signup/login forms and whatnot, and just trust the id tokens from that system.” Auth0, Keycloak, FusionAuth, etc. And again you’ll be dealing with OIDC and JWTs. If you want to manage your own usernames, passwords, signup/login pages, password reset flows, MFA flows, etc., then yeah, I’d go with traditional sessions stored in a db/cache that you manage, and auth tokens are just session ids. But if you want to outsource all of that, plus support SSO, then the id token you deal with will not be traditional session tokens, they’ll most likely be JWTs issued by someone else, where you just verify the signature.
  - layoutIfNeeded 5y ago
    And how do you log out?
    - quonn 5y ago
      The token is short lived (or should be!) and lost to the client. If that is good enough or not depends on the use case. For example, if you don‘t trust the client you also cannot trust the logout button or know that the login credentials are not compromised. So you would need a scenario where you get a token (let‘s say valid for an hour) and you use it on a computer that you trust and then someone can copy the token but afterwards you somehow trust the device again. What am I missing? Additionally most people never actively log out (especially on personal devices which are like 99%) so it’s practical to push a small list of invalidated and not yet expired tokens to all service caches in the rare case someone actually presses that logout button. Certainly much cheaper than checking them on each request or updating a cache of all sessions.
wasnthere 5y ago
Minor nitpick— “Often, sessions and cookies are described as 2 different things, but they’re really not. A session needs a cookie to work.” This is false. Inital JAVA Servlet specifications supported session id in the URL.
- alexjplant 5y ago
  I also seem to recall PHP doing this in the form of PHPSESSID in the query string. It's a bad idea no matter who's doing it though. It enables accidental session-jacking (unless you turn on annoying countermeasures like invalidating sessions when IPs change and so forth), reduces cacheability, and a whole bunch of other things that come with leaking a secret in the URL. I don't think JWTs are a panacea but they beat the heck out of 2003-era session management.
- treve 5y ago
  Yeah, I got this comment elsewhere too. I decided to not edit, because I think current standards at least strongly discourage session id's in urls, and this functionality is basically obsolete. Sessions requiring cookies felt like a reasonable approximation, and I've already had to hedge so many other statements =)
- IgorPartola 5y ago
  You can also just use Basic auth and get an Authentication header sent with every request. You know, what auth systems should have been using all along.
- nwsm 5y ago
  I don't think a counterexample (an ill-advised one at that) makes "Often, ..." false.
rcurry 5y ago
To be perfectly honest I thought JWTs made a lot of sense until I actually started trying to deploy them in a SAAS side project I was working on. It turned into a comedy of errors and I just decided to go back to cookie based authentication which worked out much better for me. I like the idea, but in practice JWTs were more hassle than they were worth.
- DrBenCarson 5y ago
  Cookies and JWTs are not mutually exclusive. Cookies containing JWTs are my MO.
ridethebike 5y ago
Does JWT always imply statelessness? We use JWT to send bunch of public claims around, one of which is session_id which refers to session in backend cache. Are we doing it wrong?
- layoutIfNeeded 5y ago
  Yes, you’re doing it wrong. You could store these “claims” in the same backend cache, keyed by the session_id.
  - spyspy 5y ago
    But maybe it’s useful to have some metadata in the jwt as well that doesn’t need to be verified by the backend?
    - ridethebike 5y ago
      That's more or less what we ended up with. We could choose one the following two extremes: a) Store sessionId as a cookie on the browser, pull all details on backend from cache server - requires network call every time when any tiny user detail is needed, not a showstopped and it worked for us for quite a while but we wanted something more convenient. b) Fully stateless backend, keep entire session in JWT - our user's session is on the huge, plus user's session has private data (we declined this option rather quickly) Instead we ended up with JWT which contains sessionId + bunch of most commonly accessed user properties (various identifiers, roles, login time, etc). Now it seems like that somehow I missed this "JWT means stateless" thingy, well, let's see what people say.
      - layoutIfNeeded 5y ago
        So if a user’s role changes (e.g. some privileges are revoked), they can still act in their old role until their token expires? Sounds like you have a security issue. Which website is this again?
        5y ago
rc_mob 5y ago
this author is a fucking genius. i always say that the smartest people can take complex subjects and make them seem simple. this dude turns sessions and jwt into childsplay. this guy is a fucking genius.
cookiesboxcar 5y ago
What is the better alternative if you want a stateless backend?
- Lazare 5y ago
  The point is that you probably don't want a truly stateless backend. What you probably want is to store a small amount of critical state in a very fast, very scalable KVS, allowing most of the backend to be stateless. So much of the discussion around JWTs boils down to "I want a stateful backend, how do I use JWTs for this?" (Answer: Not well. Why use JWTs?) Or "I have implemented a stateless backend, I'm using JWTs, how do I work around the limitations inherent in being stateless without adding state?" (Answer: You can't. Why are you using a stateless backend?) That being said, if you really DO want a JWT replacement: PASETO, Fernet, and Branca are all possibilties. See, eg, https://www.scottbrady91.com/JOSE/Alternatives-to-JWTs https://www.scottbrady91.com/JOSE/Alternatives-to-JWTs There's also Macaroons, but I don't know much about them (http://macaroons.io/ http://macaroons.io/).
  - cookiesboxcar 5y ago
    Thanks for the thoughtful reply. I’m thinking in an enterprise context, where I have many apps, many apis, many teams. Bolting auth to the gateway (with jwt) makes a lot of sense, and for very sensitive endpoints, maintain a blacklist. The high-perf kv is nice and all, but also quite complex at “enterprise” scale (meaning, lots of apps/people not throughput)
    - Lazare 5y ago
      That's fair. Although you can bolt auth to the gateway with sessions, too. Perfectly valid design to inspect the request at the gateway, strip off the cookie, look up the session, then attach the session data to the request and forward it off to your internal micro services. Authn at the edge makes a ton of sense when you hit a certain scale, or if you adopt certain patterns, but a lot of the mechanics (cookies versus other headers versus included with the request, signed payloads versus opaque tokens) are orthogonal to that. Plenty of people have adopted JWTs because they're "better for microservices", then next thing you know they've got a 80 different microservices all independently checking the JWT against a centralised revocation list. (...well, you HOPE all 80 are doing that, but inevitably, some won't be...) I think handing authn right is more about culture than any specific tech, really.
damon_c 5y ago
I feel like the author doesn't mention one thing that I always thought was one the best advantages of using tokens stored in browser localstorage instead of cookies which is that the risks of CSRF attacks are lower/gone? Cookies _always_ get sent with every request, so an attacker site can make a request to your API and if the user is logged in there, they can do as they please with that user's session... so CSRF tokens then need to be sent with any request which adds a bunch of other complexity. If authentication is handled with a token stored in localstorage rather than a cookie, no other site has access to the token and thus through more authentication hoops one need not jump. Am I just horribly confused and wrong about all this?
- arkadiyt 5y ago
  It's an orthogonal issue - you can store JWTs in cookies and you can store session ids in local storage.
- shakna 5y ago
  This is only true for cookies that do not have the SameSite=strict attribute. Cookies that have that value won't be sent by a cross-origin request.
- anaphor 5y ago
  No, you're not wrong. But I would go further and say JWTs should be obsoleted by using an object-capability model (see: http://habitatchronicles.com/2017/05/what-are-capabilities/ http://habitatchronicles.com/2017/05/what-are-capabilities/ ) which is a more fleshed out way of using unique unforgeable "tokens" to access things. The ocap model is tailor made to solve the problem that CSRF is an instance of (confused deputy attacks).
  - monocasa 5y ago
    I was under the impression that the right way to use JWTs is as object capabilities, much like Kerberos tickets. Can you expand a little more on how you believe they should be used versus how they shouldn't?
blackoil 5y ago
JWT are useful where logouts are rare (games/apps), high API volume or some latency between logout and actual logout is acceptable. Think of apps like Uber. Millions of DAU, but rarely people explicitly log out. If your logged-out user list is 5-6 order smaller than active users, it is easy to replicate/cache that. Very high API volume to many different services. Apart from few, majority of APIs won't have major security implication, if called by a rogue actor calls them. So yeah, banks shouldn't use them, Farmville/Uber using them is perfectly fine.
- mastazi 5y ago
  > So yeah, banks shouldn't use them, Farmville/Uber using them is perfectly fine. That is true (and I think the author agrees with you in the article, see the par. about scalability). However, many of us are not working at banks, or at companies that have the scale of Uber. My main takeaway from the article, is that if you are neither of those, you might still want to opt for traditional sessions.
- lucian1900 5y ago
  Games need the ability to ban players immediately, which at the very least requires a centrally stored blacklist. That means either a query for every request or pushing the blacklist somehow.
  - c0wb0yc0d3r 5y ago
    > Games need the ability to ban players immediately Do they? I haven't cheated in games for years, but the only game I can think of that took any immediate action was StarCraft: Brood War. There were a few hacks that would result in your removal instantly. You were not banned, just disconnected. Halo 2, WoW, RuneScape all banned cheaters in waves. As far as I know they did this as a measure to further impede the cheaters trying to run tests about what actions and behaviors result in negative consequences. My (naive) approach would be short lived tokens, and a mechanism for disabling and accounts ability to refresh said tokens. I wouldn't mix account management and billing with gameplay. This would in turn force users to open a different session when trying to access this authenticated data and effectively block bad actors immediately.
alex_young 5y ago
JWTs are great! You get to use your customer’s machine to store a lot of information about them and the session in a form they can actually read in most cases, and your don’t have to do a bunch of lookups each time they connect. Sure, you have to keep a revocation list, but you do anyway, for the same reasons. If you use short lived sessions with refresh tokens you get the Goldilocks scenario where a valid user stays logged in even when they are away for a long time, and you give them control over logging out instantly on all devices and access to the data you’re using about them.
zemnmez 5y ago
1. I think it's important to compare the security issues that JWT has had to the alternative. There, 'vanilla' cookie auth (which I assume to be session IDs) is by far the biggest offender. 2. It's not true that JWT is not stateless and therefore irrevocable. RFC7519 defines 'jti' for exactly this reason: > The "jti" (JWT ID) claim provides a unique identifier for the JWT. > The identifier value MUST be assigned in a manner that ensures that > there is a negligible probability that the same value will be > accidentally assigned to a different data object; if the application > uses multiple issuers, collisions MUST be prevented among values > produced by different issuers as well. The "jti" claim can be used > to prevent the JWT from being replayed. The "jti" value is a case- > sensitive string. Use of this claim is OPTIONAL. I think the rise of JWT stems from the fact that unlike traditional auth tokens (see the bundle of entropy legacy OAuth tokens were) they are human readable. When I set up an OAuth API that a user hits, I can exchange a short lived OIDC id token for a long lived capability based bearer for greater security -- and when developers use my API it's easy for them to tell why their capability token doesn't work without having to fire off a bunch of requests and guess. Edit: it occurs to me that the question of the JWT being 'stateless' might be about how session based storage often changes, but a JWT is largely immutable. Just for what it's worth, a session should not be revoked simply by removing it from the user cookie, or an attacker can persist simply by refusing to allow the cookie to be removed.
herpderperator 5y ago
As an side, the author mentions that people who use JWT instead of sessions can be likened to those who learn React/SPAs instead of conventional approaches: > This is similar to many newer developers learning how to build SPAs with React before server-rendered HTML. Experienced devs would likely feel that server-rendered HTML should probably be your default choice, and building an SPA when needed, but this is not what new developers are typically taught. I do agree with that point. It's important to learn the fundamentals before jumping into large frameworks and potentially over-engineering things in the future.
billti 5y ago
I’ve spent the last couple weeks ripping out JWTs from a site and just using cookies for auth, being that the site and the REST APIs are all on the same domain & servers anyway, and doing all the OIDC/OAuth and refresh token handling on the (ASP.Net Core) backend. I have to say, considering how “simple” some of this stuff is conceptually, it’s been surprisingly complex with a lot of nuance in areas. I can see why they say “never role your own security”. It is dangerously complex even to implement common patterns well. I hope future standards and frameworks can make this space simpler and safer.
nichch 5y ago
The amount of JWT tutorials available right now is absolutely overwhelming. I found myself worried actually that session tokens were insecure just because I could not find recent documentation/tutorials on them. I asked for suggestions on r/node for alternatives to JWT and the first comment was "Just use JWT".
- spookthesunset 5y ago
  Because JWT is the right answer for most scenarios. It's the best of both worlds when done correctly. You aren't blocking most of your requests waiting on your auth backend and for requests that actually need to have up-to-the-instant knowledge of a token's validity, you can always elect to hit up the auth backend anyway. It provides a hell of a lot of flexibility in terms of how you design your authentication architecture. For example it can let you use the same set of tokens for all your API's as you use for "web" traffic. It can reduce page latency. It can substantially reduce the footprint required for your auth backend. It's pretty awesome. It is just mis-understood because people don't understand it. They assume that you have to invent some kind of "token revokation" system when people log out... nope. I assert unless you are a bank or something, 99% of your authenticated traffic is read-heavy and can tollerate 5 minutes worth of somebody getting ahold of a token that was used for a logged out session. All the write traffic and "sensitive" read traffic can just hit up the backend server to do real-time token validation. For example here on HN 99% of authenticated requests are just to view this page, all this traffic doesn't need to insta-verify the auth token. The "post comment", "vote" and "change password" traffic makes up >1% of the traffic and can be "insta-verified" against the auth server. Who gives a shit if somebody impersonates that session for up to five minutes if they still can't comment or vote? The odds of it happening are minuscule and the damage isn't really bad...
  - treve 5y ago
    If the simple thing is sufficient, don't do the complex thing. You say that JWT is the right answer for most scenarios, I think that's not true. Aside from revoking, there's risk in complexity and I did my best in providing evidence that complexity causes real-world issues. You allude to this when you said "if done right", but that's a big if. I think this tends to fall deaf on some people's ears, because nobody feels that they might be the one to mess up JWT and inadvertently introduce vulnerabilities. Perhaps that is true for you, but the added complexity _is_ causing real-world security problems for actual developers. The advantages I'm hearing is 'not blocking requests' and 'reduces latency' (which sounds like the same thing), but how much does this really matter? How much latency do you think this is? Has this really been a bottleneck for you? You might well be part of the small group where every 5ms matters, but it would be disingenuous to suggest that that's true for "most scenarios". Most systems can bear an extra Redis fetch. I'll concede it might just work better/simpler in your architecture, especially since you mention a dedicated auth backend, but shaving a few ms of a request is not a good enough universal reason given the drawbacks.
haolez 5y ago
An insanity has just occured to me: you could update (i.e. regenerate) the user's ID to invalidate tokens, fixing the logout issue and keeping the architecture stateless :)
- SkyPuncher 5y ago
  Wow. This is a great idea.
- treve 5y ago
  This implies you would also need to know if the user ID exists before you use it, which means a look up. (because it might be 'regenerated' and no longer valid). If you take that one step further and just introduce disposable user ids, that point to a "real" user id, you've basically reinvented the session ID.
  - haolez 5y ago
    That's the same as when you have a "normal" user ID in the token. You have to bind the request to your user's data _somewhere_.
andyp-kw 5y ago
This is actually the best description of JWT for dummies that I've found so far.
kgeist 5y ago
How about salt the token with an additional user-specific random string. During log-out, you replace the random string so it no longer matches. Then, we can have partial check (only signature validation and expiry time) and full check (compare with the salt hitting some store). Full checks can be done only for API calls which deal with sensitive stuff or/and for writes (writes are less common than reads) For example, fetching an article on something like New York Times would only require a partial check, but the profile page would have full checks. Does it make sense?
- jayd16 5y ago
  If you need to look up the salt for every user on every verify, you're wasting any caching advantage. If you cache the salt, you're reintroducing the cache clearing headaches.
  - kgeist 5y ago
    Not on every verify, that's what full checks are for. The salt isn't saved in the token for caching purposes, it is used to invalidate the token when a user logs out (detected only on full check when salts change). Salt is stored inside the token like other JWT data so it can be ignored for non-sensitive calls (partial check).
    - deleted 5y ago
      [deleted]
jeswin 5y ago
The article and associated links are weak on details - most of them are some form of setting the alg incorrectly. > First, it’s a complicated standard Actually it's remarkably simple and very well thought out; I frequently generate them in plain bash for testing. It is the simplicity that makes me trust JWT (where appropriate). > If they’re (Auth0) not safe, what chance does the general (developer) public have? Auth0 forgot to check latter case in alg = 'none', a very basic coding error. These errors can happen anywhere, and anyway use a whitelist for algorithms. The other links are quite similar, such as using a weak alg. > A last issue with JWT is that they are relatively big, and when used in cookies it adds a lot of per-request overhead. Most apps simply put userid and roles in the JWT, and that's negligible overhead. Of course there are people who do it wrong, but there are also people who store 10MB of data in a session. My view is that JWT has a place in the future, and it works well even with decentralized systems. The ecosystem around JWT is rich, and over the years has evolved to solve many common usecases which come up in production. An example would be the JWK/JWKS spec, which greatly simplify how verification keys can be fetched.
Abimelex 5y ago
> Experienced devs would likely feel that server-rendered HTML should probably be your default choice, and building an SPA when needed, [...] Is there any good article why SSR is any better than SPA? I really do not see any advantages of SSR, especially for pages where you need to be logged in and data to be displayed is acquired via an API.
- Tade0 5y ago
  They're generally "low power". -On average less data is transferred - even in modern frameworks bundles still weigh more than multiple static pages. -Small(or non-existent) JS bundles mean much less time/energy spent compiling - this is currently the largest task when rendering a page for the first time. Both of these advantages are especially visible on mobile devices.
revskill 5y ago
The problem is lack of thorough best practices on how to using JWT on a JAMStack WITHOUT secure, same-site cookies. There're many edge cases to cover but as i see, there's none of best practice guide on how to do your own !
mkl95 5y ago
I'd say this heavily depends on your stack. In my experience Django Rest Framework with JWT + Vue or React on the frontend + some JS package that stores and refreshes tokens is solid as a rock and easy to implement/maintain. Your end users will never need to know what JWT means and you won't need to do any kind of token management. As far as I know, Instagram's stack is a variant of this.
- seanieb 5y ago
  7ish years as a security engineer and all my gut instincts tell me that you’re site has auth bugs just from hearing the spec. It might be perfectly secure, but if I was put on your project tomorrow I’d be budgeting weeks to review and work on that auth system. And even then it’s a foot gun waiting for other devs to screw it up later on.
  - deleted 5y ago
    [deleted]
  - mkl95 5y ago
    What are you on about? You should know the difference between a short sentence and a spec after 7 years.
emrah 5y ago
If your end user is using a browser, the session/cookie is the right mechanism to use. Even though it seems more convenient to use JWT instead of a regular cookie, since JWT is not recognized by browsers, there are security gotchas when using JWT as a replacement for session. JWT makes sense to authenticate microservices within a trusted network where a gateway server logges the user into the network using a session. Microservices within the network communicate via JWT where the user does not have direct access to them. There should be a separate server that does the lookup for specific services.
BiteCode_dev 5y ago
"Statistically, most of us are building applications that won’t make a Raspberry Pi break a sweat." I keep repeating that, but the dev community is really susceptible to the "temporary embarrassed billionaire" syndrome.
yurish 5y ago
Sorry for offtopic. Can somebody recommend up-to-date book discussing authentication and access control methods in web applications/API, there strengths and drawbacks?
young_unixer 5y ago
> However, these new technologies create a lot more buzz than their simpler counterparts, and if enough people keep talking about the hot thing, eventually this can translate to actual adoption, despite it being a sub-optimal choice for the majority of simple use-cases. I hate this about the Node/Javascript community. Whenever I need to learn how to do something in Node js, 4 out of 5 blog posts or tutorials will be about some overly complicated technology or new, shiny thing instead of the classical way. Man, I just want to do the same shit we were doing in PHP 10 years ago, but this time I want to see how to do it in Node/Express. Is that too much to ask?
- n_ary 5y ago
  Honestly, most Node/Express tutorials are 1:1 copies(try googling sometimes). Not Node/Express specific though, majority tutorials are material to signal author's knowledge towards potential gigs/jobs, not to share knowledge. Which is why a hello-world in Reactjs tutorial needs to setup Redux, or a java tutorial brings in SpringBoot etc.. [Disclaimer: my own experience, ymmv.]
Tade0 5y ago
There's a neat little chart which explains why you'd probably be better off not using JWT: http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work/ http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-fo...
logbiscuitswave 5y ago
> it has a ton of features and a very large scope, which gives it a large surface area for potential mistakes, by either library authors or users of those libraries I mean that could apply to so many things — PKI, Windows permissions, and countless other things. It definitely strikes a chord with me.

335 points by mfbx9da4 5y ago

> If they’re not safe, what chance does the general (developer) public have? Something I've been wondering is, do we really have any evidence that the average Auth0 developer is more of a security expert than any other dev? I'm sure they have security experts on staff designing systems but it doesn't seem likely that everyone doing the building is an expert. They are as likely as any to code in mistakes

goalieca 5y ago
> Something I've been wondering is, do we really have any evidence that the average Auth0 developer is more of a security expert than any other dev? Security companies have average developers just like everyone else. They probably do have better domain knowledge from working on their product but they will miss other important things. The real difference in security comes from product management. Almost everyone I've talked to has some sort of risk assessment process where these sorts of things are laid down in great detail. The leading companies will invest in not only trying to discover weaknesses but will plan to mitigate or resolve the issues within a reasonable timeline.

rsj_hn 5y ago

JWTs are good for API tokens, not end users. If you use JWTs for your cookies/session state, then you'll still need to maintain a table of valid JWTs and expire them when the user logs out, and thus you will not be able to use JWTs as they were intended to be used, which is as stateless tokens. Most security auditors/certifications/compliance requirements do not consider even a 5 minute lag acceptable for user driven logout. The definition of logout is that when the user presses the logout button, all the session data is invalidated server-side during roughly the time it takes for a request/response roundtrip. Thus there is no benefit to using a non-opaque high entropy string for user sessions, even though there is a good benefit to using JWTs as API tokens for back-end services (esp. microservices) that do not have browser logout requirements.

aflag 5y ago
Why can't you just delete the cookie when the user logs out?
- jakereps 5y ago
  That token itself is still valid - regardless of whether or not their browser still has it stored.
- hermanradtke 5y ago
  The issue is not deleting the cookie. The issue is that the JWT can still be used as a valid session unless you have some sort of blocklist. Once you introduce a blocklist, you might as well ditch the JWT and use some opaque token stored in a table.
  - axiosgunnar 5y ago
    the entire article could be summed up with this post tbh
  - remram 5y ago
    Is that a problem though? Does your threat model include clients that correctly send logout requests when they're supposed to but don't delete cookies when they're told?
    - colinclerk 5y ago
      Your application should certainly have some resolution to an account being hacked or a session token being stolen. No expiry and no denylist means an attacker can cause problems until you patch your code.
    - SigmundA 5y ago
      Never trust the client, ever.
      - 5y ago

frompdx 5y ago

The author says one of the selling points of JWT is scale, and points out many will not need to concern themselves with scale and to stick with simple solutions. But I am curious to know if any on HN is using session cookies at scale and how they solve the scalability issues of session cookies alluded to in the article?

nkozyra 5y ago
I think the whole "sessions don't scale" predates an era of cheap, shardable/distributable and performant options from NoSQL to RDBMS. It used to be a serious bottleneck for even smaller sites. But they also used to stick them in stodgy, table-locking storage engines in the same database as the rest of their application. Times have changed and I really believe you can manage cookies<->sessions without too much overhead. And if you're willing to let a JWT have a 5-minute max life, you could similarly cache your session responses for 5 minutes. Like all things, there comes a tipping point eventually. But it's not as early or as drastic as it once was.
echelon 5y ago
I've been heavily involved in an active-active session service that handles 100kqps+. It's not that hard to achieve with Redis. If you model your sessions as an acyclical state machine, you can quickly consolidate a single view of all sessions globally. Beyond this, it's valuable to be able to scope sessions, invalidate subsets of sessions, create delegate sessions, provide an audit trail for internal support staff using session impersonation, etc. JWTs can't give you a lot of the rich security behaviors that real sessions can, such as asking a user to use 2FA for editing sensitive data if they haven't provided that information in the last 15 minutes. Or estimate user idle time.
- jruthers 5y ago
  Would you be able to expand on scoped sessions, invalidated subsets, delegated sessions? Our roadmap has a big emphasis on improved session management and these are ideas we haven't considered and I'm keen to understand more.

porphyra 5y ago

Why is "JWT" not defined or explained until I scroll a few pages down and find one that's hyperlinked? I thought it was talking about the James Webb Telescope this whole time.

CraftThatBlock 5y ago
"JWT" is a pretty popular term. The James Webb telescope is the JWST (space being the S)
treve 5y ago
The first one is hyperlinked, unless you count the title.

VincentEvans 5y ago

I think you are overlooking the main benefit of JWT - is to allow authentication by a trusted third party, thus enabling single sign on, eliminating the need for password storage and management, login forms, etcetera.

layoutIfNeeded 5y ago
You’ve failed to understand the article. Please don’t write backend software.
yashap 5y ago
Not sure why you’re being downvoted, but agreed. Tonnes of apps want to support SSO, and most modern SSO systems use Open ID Connect, where the id tokens are JWTs. If you want to let your users login via Google, Facebook, Okta, whatever, then you’ll be dealing JWTs. And once you’re doing that, it’s a small step to say: “even if my users want to signup/login via username and password, I’d rather not manage that myself. I’d rather use a 3rd party system to store the passwords, implement MFA and password recovery and signup/login forms and whatnot, and just trust the id tokens from that system.” Auth0, Keycloak, FusionAuth, etc. And again you’ll be dealing with OIDC and JWTs. If you want to manage your own usernames, passwords, signup/login pages, password reset flows, MFA flows, etc., then yeah, I’d go with traditional sessions stored in a db/cache that you manage, and auth tokens are just session ids. But if you want to outsource all of that, plus support SSO, then the id token you deal with will not be traditional session tokens, they’ll most likely be JWTs issued by someone else, where you just verify the signature.
- layoutIfNeeded 5y ago
  And how do you log out?
  - quonn 5y ago
    The token is short lived (or should be!) and lost to the client. If that is good enough or not depends on the use case. For example, if you don‘t trust the client you also cannot trust the logout button or know that the login credentials are not compromised. So you would need a scenario where you get a token (let‘s say valid for an hour) and you use it on a computer that you trust and then someone can copy the token but afterwards you somehow trust the device again. What am I missing? Additionally most people never actively log out (especially on personal devices which are like 99%) so it’s practical to push a small list of invalidated and not yet expired tokens to all service caches in the rare case someone actually presses that logout button. Certainly much cheaper than checking them on each request or updating a cache of all sessions.

wasnthere 5y ago

Minor nitpick— “Often, sessions and cookies are described as 2 different things, but they’re really not. A session needs a cookie to work.” This is false. Inital JAVA Servlet specifications supported session id in the URL.

alexjplant 5y ago
I also seem to recall PHP doing this in the form of PHPSESSID in the query string. It's a bad idea no matter who's doing it though. It enables accidental session-jacking (unless you turn on annoying countermeasures like invalidating sessions when IPs change and so forth), reduces cacheability, and a whole bunch of other things that come with leaking a secret in the URL. I don't think JWTs are a panacea but they beat the heck out of 2003-era session management.
treve 5y ago
Yeah, I got this comment elsewhere too. I decided to not edit, because I think current standards at least strongly discourage session id's in urls, and this functionality is basically obsolete. Sessions requiring cookies felt like a reasonable approximation, and I've already had to hedge so many other statements =)
IgorPartola 5y ago
You can also just use Basic auth and get an Authentication header sent with every request. You know, what auth systems should have been using all along.
nwsm 5y ago
I don't think a counterexample (an ill-advised one at that) makes "Often, ..." false.

rcurry 5y ago

To be perfectly honest I thought JWTs made a lot of sense until I actually started trying to deploy them in a SAAS side project I was working on. It turned into a comedy of errors and I just decided to go back to cookie based authentication which worked out much better for me. I like the idea, but in practice JWTs were more hassle than they were worth.

DrBenCarson 5y ago
Cookies and JWTs are not mutually exclusive. Cookies containing JWTs are my MO.

ridethebike 5y ago

Does JWT always imply statelessness? We use JWT to send bunch of public claims around, one of which is session_id which refers to session in backend cache. Are we doing it wrong?

layoutIfNeeded 5y ago
Yes, you’re doing it wrong. You could store these “claims” in the same backend cache, keyed by the session_id.
- spyspy 5y ago
  But maybe it’s useful to have some metadata in the jwt as well that doesn’t need to be verified by the backend?
  - ridethebike 5y ago
    That's more or less what we ended up with. We could choose one the following two extremes: a) Store sessionId as a cookie on the browser, pull all details on backend from cache server - requires network call every time when any tiny user detail is needed, not a showstopped and it worked for us for quite a while but we wanted something more convenient. b) Fully stateless backend, keep entire session in JWT - our user's session is on the huge, plus user's session has private data (we declined this option rather quickly) Instead we ended up with JWT which contains sessionId + bunch of most commonly accessed user properties (various identifiers, roles, login time, etc). Now it seems like that somehow I missed this "JWT means stateless" thingy, well, let's see what people say.
    - layoutIfNeeded 5y ago
      So if a user’s role changes (e.g. some privileges are revoked), they can still act in their old role until their token expires? Sounds like you have a security issue. Which website is this again?
      - 5y ago

rc_mob 5y ago

this author is a fucking genius. i always say that the smartest people can take complex subjects and make them seem simple. this dude turns sessions and jwt into childsplay. this guy is a fucking genius.

cookiesboxcar 5y ago

What is the better alternative if you want a stateless backend?

Lazare 5y ago
The point is that you probably don't want a truly stateless backend. What you probably want is to store a small amount of critical state in a very fast, very scalable KVS, allowing most of the backend to be stateless. So much of the discussion around JWTs boils down to "I want a stateful backend, how do I use JWTs for this?" (Answer: Not well. Why use JWTs?) Or "I have implemented a stateless backend, I'm using JWTs, how do I work around the limitations inherent in being stateless without adding state?" (Answer: You can't. Why are you using a stateless backend?) That being said, if you really DO want a JWT replacement: PASETO, Fernet, and Branca are all possibilties. See, eg, https://www.scottbrady91.com/JOSE/Alternatives-to-JWTs https://www.scottbrady91.com/JOSE/Alternatives-to-JWTs There's also Macaroons, but I don't know much about them (http://macaroons.io/ http://macaroons.io/).
- cookiesboxcar 5y ago
  Thanks for the thoughtful reply. I’m thinking in an enterprise context, where I have many apps, many apis, many teams. Bolting auth to the gateway (with jwt) makes a lot of sense, and for very sensitive endpoints, maintain a blacklist. The high-perf kv is nice and all, but also quite complex at “enterprise” scale (meaning, lots of apps/people not throughput)
  - Lazare 5y ago
    That's fair. Although you can bolt auth to the gateway with sessions, too. Perfectly valid design to inspect the request at the gateway, strip off the cookie, look up the session, then attach the session data to the request and forward it off to your internal micro services. Authn at the edge makes a ton of sense when you hit a certain scale, or if you adopt certain patterns, but a lot of the mechanics (cookies versus other headers versus included with the request, signed payloads versus opaque tokens) are orthogonal to that. Plenty of people have adopted JWTs because they're "better for microservices", then next thing you know they've got a 80 different microservices all independently checking the JWT against a centralised revocation list. (...well, you HOPE all 80 are doing that, but inevitably, some won't be...) I think handing authn right is more about culture than any specific tech, really.

damon_c 5y ago

I feel like the author doesn't mention one thing that I always thought was one the best advantages of using tokens stored in browser localstorage instead of cookies which is that the risks of CSRF attacks are lower/gone? Cookies _always_ get sent with every request, so an attacker site can make a request to your API and if the user is logged in there, they can do as they please with that user's session... so CSRF tokens then need to be sent with any request which adds a bunch of other complexity. If authentication is handled with a token stored in localstorage rather than a cookie, no other site has access to the token and thus through more authentication hoops one need not jump. Am I just horribly confused and wrong about all this?

arkadiyt 5y ago
It's an orthogonal issue - you can store JWTs in cookies and you can store session ids in local storage.
shakna 5y ago
This is only true for cookies that do not have the SameSite=strict attribute. Cookies that have that value won't be sent by a cross-origin request.
anaphor 5y ago
No, you're not wrong. But I would go further and say JWTs should be obsoleted by using an object-capability model (see: http://habitatchronicles.com/2017/05/what-are-capabilities/ http://habitatchronicles.com/2017/05/what-are-capabilities/ ) which is a more fleshed out way of using unique unforgeable "tokens" to access things. The ocap model is tailor made to solve the problem that CSRF is an instance of (confused deputy attacks).
- monocasa 5y ago
  I was under the impression that the right way to use JWTs is as object capabilities, much like Kerberos tickets. Can you expand a little more on how you believe they should be used versus how they shouldn't?

blackoil 5y ago

JWT are useful where logouts are rare (games/apps), high API volume or some latency between logout and actual logout is acceptable. Think of apps like Uber. Millions of DAU, but rarely people explicitly log out. If your logged-out user list is 5-6 order smaller than active users, it is easy to replicate/cache that. Very high API volume to many different services. Apart from few, majority of APIs won't have major security implication, if called by a rogue actor calls them. So yeah, banks shouldn't use them, Farmville/Uber using them is perfectly fine.

mastazi 5y ago
> So yeah, banks shouldn't use them, Farmville/Uber using them is perfectly fine. That is true (and I think the author agrees with you in the article, see the par. about scalability). However, many of us are not working at banks, or at companies that have the scale of Uber. My main takeaway from the article, is that if you are neither of those, you might still want to opt for traditional sessions.
lucian1900 5y ago
Games need the ability to ban players immediately, which at the very least requires a centrally stored blacklist. That means either a query for every request or pushing the blacklist somehow.
- c0wb0yc0d3r 5y ago
  > Games need the ability to ban players immediately Do they? I haven't cheated in games for years, but the only game I can think of that took any immediate action was StarCraft: Brood War. There were a few hacks that would result in your removal instantly. You were not banned, just disconnected. Halo 2, WoW, RuneScape all banned cheaters in waves. As far as I know they did this as a measure to further impede the cheaters trying to run tests about what actions and behaviors result in negative consequences. My (naive) approach would be short lived tokens, and a mechanism for disabling and accounts ability to refresh said tokens. I wouldn't mix account management and billing with gameplay. This would in turn force users to open a different session when trying to access this authenticated data and effectively block bad actors immediately.

alex_young 5y ago

JWTs are great! You get to use your customer’s machine to store a lot of information about them and the session in a form they can actually read in most cases, and your don’t have to do a bunch of lookups each time they connect. Sure, you have to keep a revocation list, but you do anyway, for the same reasons. If you use short lived sessions with refresh tokens you get the Goldilocks scenario where a valid user stays logged in even when they are away for a long time, and you give them control over logging out instantly on all devices and access to the data you’re using about them.

zemnmez 5y ago

1. I think it's important to compare the security issues that JWT has had to the alternative. There, 'vanilla' cookie auth (which I assume to be session IDs) is by far the biggest offender. 2. It's not true that JWT is not stateless and therefore irrevocable. RFC7519 defines 'jti' for exactly this reason: > The "jti" (JWT ID) claim provides a unique identifier for the JWT. > The identifier value MUST be assigned in a manner that ensures that > there is a negligible probability that the same value will be > accidentally assigned to a different data object; if the application > uses multiple issuers, collisions MUST be prevented among values > produced by different issuers as well. The "jti" claim can be used > to prevent the JWT from being replayed. The "jti" value is a case- > sensitive string. Use of this claim is OPTIONAL. I think the rise of JWT stems from the fact that unlike traditional auth tokens (see the bundle of entropy legacy OAuth tokens were) they are human readable. When I set up an OAuth API that a user hits, I can exchange a short lived OIDC id token for a long lived capability based bearer for greater security -- and when developers use my API it's easy for them to tell why their capability token doesn't work without having to fire off a bunch of requests and guess. Edit: it occurs to me that the question of the JWT being 'stateless' might be about how session based storage often changes, but a JWT is largely immutable. Just for what it's worth, a session should not be revoked simply by removing it from the user cookie, or an attacker can persist simply by refusing to allow the cookie to be removed.

herpderperator 5y ago

As an side, the author mentions that people who use JWT instead of sessions can be likened to those who learn React/SPAs instead of conventional approaches: > This is similar to many newer developers learning how to build SPAs with React before server-rendered HTML. Experienced devs would likely feel that server-rendered HTML should probably be your default choice, and building an SPA when needed, but this is not what new developers are typically taught. I do agree with that point. It's important to learn the fundamentals before jumping into large frameworks and potentially over-engineering things in the future.

billti 5y ago

I’ve spent the last couple weeks ripping out JWTs from a site and just using cookies for auth, being that the site and the REST APIs are all on the same domain & servers anyway, and doing all the OIDC/OAuth and refresh token handling on the (ASP.Net Core) backend. I have to say, considering how “simple” some of this stuff is conceptually, it’s been surprisingly complex with a lot of nuance in areas. I can see why they say “never role your own security”. It is dangerously complex even to implement common patterns well. I hope future standards and frameworks can make this space simpler and safer.

nichch 5y ago

The amount of JWT tutorials available right now is absolutely overwhelming. I found myself worried actually that session tokens were insecure just because I could not find recent documentation/tutorials on them. I asked for suggestions on r/node for alternatives to JWT and the first comment was "Just use JWT".

spookthesunset 5y ago
Because JWT is the right answer for most scenarios. It's the best of both worlds when done correctly. You aren't blocking most of your requests waiting on your auth backend and for requests that actually need to have up-to-the-instant knowledge of a token's validity, you can always elect to hit up the auth backend anyway. It provides a hell of a lot of flexibility in terms of how you design your authentication architecture. For example it can let you use the same set of tokens for all your API's as you use for "web" traffic. It can reduce page latency. It can substantially reduce the footprint required for your auth backend. It's pretty awesome. It is just mis-understood because people don't understand it. They assume that you have to invent some kind of "token revokation" system when people log out... nope. I assert unless you are a bank or something, 99% of your authenticated traffic is read-heavy and can tollerate 5 minutes worth of somebody getting ahold of a token that was used for a logged out session. All the write traffic and "sensitive" read traffic can just hit up the backend server to do real-time token validation. For example here on HN 99% of authenticated requests are just to view this page, all this traffic doesn't need to insta-verify the auth token. The "post comment", "vote" and "change password" traffic makes up >1% of the traffic and can be "insta-verified" against the auth server. Who gives a shit if somebody impersonates that session for up to five minutes if they still can't comment or vote? The odds of it happening are minuscule and the damage isn't really bad...
- treve 5y ago
  If the simple thing is sufficient, don't do the complex thing. You say that JWT is the right answer for most scenarios, I think that's not true. Aside from revoking, there's risk in complexity and I did my best in providing evidence that complexity causes real-world issues. You allude to this when you said "if done right", but that's a big if. I think this tends to fall deaf on some people's ears, because nobody feels that they might be the one to mess up JWT and inadvertently introduce vulnerabilities. Perhaps that is true for you, but the added complexity _is_ causing real-world security problems for actual developers. The advantages I'm hearing is 'not blocking requests' and 'reduces latency' (which sounds like the same thing), but how much does this really matter? How much latency do you think this is? Has this really been a bottleneck for you? You might well be part of the small group where every 5ms matters, but it would be disingenuous to suggest that that's true for "most scenarios". Most systems can bear an extra Redis fetch. I'll concede it might just work better/simpler in your architecture, especially since you mention a dedicated auth backend, but shaving a few ms of a request is not a good enough universal reason given the drawbacks.

haolez 5y ago

An insanity has just occured to me: you could update (i.e. regenerate) the user's ID to invalidate tokens, fixing the logout issue and keeping the architecture stateless :)

SkyPuncher 5y ago
Wow. This is a great idea.
treve 5y ago
This implies you would also need to know if the user ID exists before you use it, which means a look up. (because it might be 'regenerated' and no longer valid). If you take that one step further and just introduce disposable user ids, that point to a "real" user id, you've basically reinvented the session ID.
- haolez 5y ago
  That's the same as when you have a "normal" user ID in the token. You have to bind the request to your user's data _somewhere_.

andyp-kw 5y ago

This is actually the best description of JWT for dummies that I've found so far.

kgeist 5y ago

How about salt the token with an additional user-specific random string. During log-out, you replace the random string so it no longer matches. Then, we can have partial check (only signature validation and expiry time) and full check (compare with the salt hitting some store). Full checks can be done only for API calls which deal with sensitive stuff or/and for writes (writes are less common than reads) For example, fetching an article on something like New York Times would only require a partial check, but the profile page would have full checks. Does it make sense?

jayd16 5y ago
If you need to look up the salt for every user on every verify, you're wasting any caching advantage. If you cache the salt, you're reintroducing the cache clearing headaches.
- kgeist 5y ago
  Not on every verify, that's what full checks are for. The salt isn't saved in the token for caching purposes, it is used to invalidate the token when a user logs out (detected only on full check when salts change). Salt is stored inside the token like other JWT data so it can be ignored for non-sensitive calls (partial check).
  - deleted 5y ago
    [deleted]

jeswin 5y ago

The article and associated links are weak on details - most of them are some form of setting the alg incorrectly. > First, it’s a complicated standard Actually it's remarkably simple and very well thought out; I frequently generate them in plain bash for testing. It is the simplicity that makes me trust JWT (where appropriate). > If they’re (Auth0) not safe, what chance does the general (developer) public have? Auth0 forgot to check latter case in alg = 'none', a very basic coding error. These errors can happen anywhere, and anyway use a whitelist for algorithms. The other links are quite similar, such as using a weak alg. > A last issue with JWT is that they are relatively big, and when used in cookies it adds a lot of per-request overhead. Most apps simply put userid and roles in the JWT, and that's negligible overhead. Of course there are people who do it wrong, but there are also people who store 10MB of data in a session. My view is that JWT has a place in the future, and it works well even with decentralized systems. The ecosystem around JWT is rich, and over the years has evolved to solve many common usecases which come up in production. An example would be the JWK/JWKS spec, which greatly simplify how verification keys can be fetched.

Abimelex 5y ago

> Experienced devs would likely feel that server-rendered HTML should probably be your default choice, and building an SPA when needed, [...] Is there any good article why SSR is any better than SPA? I really do not see any advantages of SSR, especially for pages where you need to be logged in and data to be displayed is acquired via an API.

Tade0 5y ago
They're generally "low power". -On average less data is transferred - even in modern frameworks bundles still weigh more than multiple static pages. -Small(or non-existent) JS bundles mean much less time/energy spent compiling - this is currently the largest task when rendering a page for the first time. Both of these advantages are especially visible on mobile devices.

revskill 5y ago

The problem is lack of thorough best practices on how to using JWT on a JAMStack WITHOUT secure, same-site cookies. There're many edge cases to cover but as i see, there's none of best practice guide on how to do your own !

mkl95 5y ago

I'd say this heavily depends on your stack. In my experience Django Rest Framework with JWT + Vue or React on the frontend + some JS package that stores and refreshes tokens is solid as a rock and easy to implement/maintain. Your end users will never need to know what JWT means and you won't need to do any kind of token management. As far as I know, Instagram's stack is a variant of this.

seanieb 5y ago
7ish years as a security engineer and all my gut instincts tell me that you’re site has auth bugs just from hearing the spec. It might be perfectly secure, but if I was put on your project tomorrow I’d be budgeting weeks to review and work on that auth system. And even then it’s a foot gun waiting for other devs to screw it up later on.
- deleted 5y ago
  [deleted]
- mkl95 5y ago
  What are you on about? You should know the difference between a short sentence and a spec after 7 years.

emrah 5y ago

If your end user is using a browser, the session/cookie is the right mechanism to use. Even though it seems more convenient to use JWT instead of a regular cookie, since JWT is not recognized by browsers, there are security gotchas when using JWT as a replacement for session. JWT makes sense to authenticate microservices within a trusted network where a gateway server logges the user into the network using a session. Microservices within the network communicate via JWT where the user does not have direct access to them. There should be a separate server that does the lookup for specific services.

BiteCode_dev 5y ago

"Statistically, most of us are building applications that won’t make a Raspberry Pi break a sweat." I keep repeating that, but the dev community is really susceptible to the "temporary embarrassed billionaire" syndrome.

yurish 5y ago

Sorry for offtopic. Can somebody recommend up-to-date book discussing authentication and access control methods in web applications/API, there strengths and drawbacks?

young_unixer 5y ago

> However, these new technologies create a lot more buzz than their simpler counterparts, and if enough people keep talking about the hot thing, eventually this can translate to actual adoption, despite it being a sub-optimal choice for the majority of simple use-cases. I hate this about the Node/Javascript community. Whenever I need to learn how to do something in Node js, 4 out of 5 blog posts or tutorials will be about some overly complicated technology or new, shiny thing instead of the classical way. Man, I just want to do the same shit we were doing in PHP 10 years ago, but this time I want to see how to do it in Node/Express. Is that too much to ask?

n_ary 5y ago
Honestly, most Node/Express tutorials are 1:1 copies(try googling sometimes). Not Node/Express specific though, majority tutorials are material to signal author's knowledge towards potential gigs/jobs, not to share knowledge. Which is why a hello-world in Reactjs tutorial needs to setup Redux, or a java tutorial brings in SpringBoot etc.. [Disclaimer: my own experience, ymmv.]

Tade0 5y ago

There's a neat little chart which explains why you'd probably be better off not using JWT: http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work/ http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-fo...

logbiscuitswave 5y ago

> it has a ton of features and a very large scope, which gives it a large surface area for potential mistakes, by either library authors or users of those libraries I mean that could apply to so many things — PKI, Windows permissions, and countless other things. It definitely strikes a chord with me.