Dangerous and incorrect information in README

[joepie91]

I'll address the problems one by one:

Secure your website/app without cookies

This is not inherently desirable. Cookies exist for a very specific purpose, and work well for that purpose.

No cookies means no annoying cookie message on your website (see: e-Privacy Directive)

This is not how the e-Privacy Directive works. Technically necessary sessions (ie. not for analytics/tracking/etc., but for keeping track of an account or similar tasks) do not fall under the consent scheme to begin with.

Similarly, cookies are not explicitly mentioned in the Directive anywhere, nor is it intended to refer to them - any kind of persistent identifier stored on a user's system by your application for non-essential purposes falls under the Directive, and that includes a JWT stored by some other mechanism.

Stateless authentication (simplifies horizontal scaling)

This is misleading. 'Stateless sessions' introduce many new issues, both security-wise and otherwise, for example:

• Inability to invalidate (not expire!) a token, eg. after an account has been found to be compromised, without reintroducing stateful architecture.
• Session data staleness; session data cannot be kept fresh without reintroducing stateful architecture.

... all the while 'solving' a problem that almost nobody actually has - in 99.99% of cases, you don't need to statelessly scale your sessions.

There are many simpler techniques such as running a dedicated and vertically scaled session storage server (eg. using Redis), 'sticky sessions', geographically clustered session servers, etc. Unless you are running at the scale of eg. Reddit, you almost certainly do not need stateless sessions.

Prevent (mitigate) Cross-Site Request Forgery (CSRF) attacks.

This is an unbelievably misleading and harmful statement. JWT is not CSRF mitigation. You have roughly two choices for working with JWTs:

• Store them in a cookie: Now you're vulnerable to CSRF again, because the whole reason CSRF works is that it depends on credentials being sent along automatically with any request to the hostname. What format those credentials have doesn't matter.
• Store them elsewhere, eg. Local Storage: Now you've just introduced a whole new class of vulnerabilities, and now your site unnecessarily requires JavaScript to work.

---

Fundamentally, JWTs are not for sessions - rather, they are primarily for transferring claims through an untrusted third-party, while preventing tampering.

At the very least, the entire "Why?" section needs to be removed (as it's simply wrong and provides harmful advice), but frankly, since it's the premise of the entire repository, I feel like the existence of the entire repository should be reconsidered. It is seriously irresponsible to give developers harmful advice like this.

[pscott-au]

Some very well thought out and articulately expressed concerns that are certainly giving me some food for thought as someone who's just started looking at the repo. I was looking for a quick example to create a JWT auth working example with Node. My interest in JWT is to provide a modern best-practice approach to session management for both REST API and js client while avoiding CORS issues. I am mildly interested in security but this isn't my motivation for using JWT although I appreciate the role that tokens can play in more comprehensive secure approaches such as OAUTH. As I first read through this repo it did strike me as including a lot of notes that the author has collected as they are building their knowledge of JWT usage etc. Although I have little investment in this repo I am inclined to believe that there is a place for a platform specific, minimalistic working example of login/logout with some supporting tools,references. As a foundation for on-boarding skills and as a starter I think the aims of this repo are good but perhaps the README does need a serious rewrite and a refocus on the aims of this type of usage of JWTs. I'd be happy to try to suggest something .. joepie91 - you clearly have a good undertanding of the issues .. could you provide some thoughts on what the real benefits of this kind of usage of JWT's really is?

[nelsonic]

Hi @joepie91, we are stoked that you have found and read our notes on JWT!
thank you for taking the time to open this issue to raise your concerns. ❤️
We'd be delighted if you would split each of your concerns into a separate issue or at least number them so to make it easier to discuss.

We respectfully disagree that the content of these notes is "Dangerous".

_Cookies_ > in The EU ePrivacy directive Recital 25, cookies _are explicitly mentioned_ 5 times:

see:
https://en.wikipedia.org/wiki/Directive_on_Privacy_and_Electronic_Communications#Cookies
or:
http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:32002L0058:EN:HTML

Granted, many websites/apps (which are not using 3rd party tracking cookies) fall under the ‘strictly necessary for the delivery of a service requested by the user’ ... which is why we use cookies in our progressively enhanced web applications. see: https://github.com/dwyl/hapi-auth-jwt2#want-to-sendstore-your-jwt-in-a-cookie

Storing JWT in _localStorage_ > While we agree that storing session data/tokens in localStorage means that JavaScript is _required_ (we don't like this either, we prefer progressive enhancement, this was meant to note an alternative option...). localStorage is how _all_ applications built with a "Backend-as-a-Service" are made, because BaaS typically do not accept cookies... Are you suggesting that half-a-million developers using Google Firebase are doing it "wrong"...? (this would be a great - separate - discussion...!)

Stateless Sessions are possible with JWTs because they have a built-in exp (expiration time) option, however we chose/prefer _not_ to make our sessions stateless instead opting to store a session id (jti) inside the JWT which gets looked up in a Redis store after the JWT has been verified. This means we can _invalidate_ a session when a person logs out or if their device is stolen and they need to revoke an active session.

Yes, the primary purpose of JWTs is to is to pass claims between parties in web application environment, that's exactly what we are using them for.

Our sessions ids or tokens could simply be a random string which gets checked server-side, but we decided to use JWTs to format and sign the session data.

Conclusion: let's update the readme to clarify things. 👍

[pscott-au]

Rather than splitting the raised issues into a set of issues as suggested by @nelsonic I tend to agree that the intent and objectives of the implementation should be clarified in the scope of the README. I don't read the issues of @joepie91 as being a criticism of the use of JWTs in the context of web applications as such, or the support of cookies as superior; rather I take the criticism as being that the description of JWT's is presented in a way that overplays or misrepresents the reason for choosing JWT.
The same concern is expressed also in #55(clarify that JWT is not encryption ...)

For me it's enough to be able to operate Firebase and my own services using a common claim that expires. I may extend it to include some state in some cases and not in others and still prefer the approach to using cookies or older access control http authentication approaches.
I like that I can use JWT tokens as part of a more sophisticated approach but I still agree that the focus on the benefits of the README should be on the problems we are looking to solve with them rather than straying to less solid ground. Much of the reference material in the README could perhaps be relegated to notes or even the Wiki as a discussion material?

I don't know if I'd necessarily say that the README is dangerous - seems a little strong

[joepie91]

Cookies > in The EU ePrivacy directive Recital 25, cookies are explicitly mentioned 5 times:

Apologies, it seems I worded it rather vaguely. While the text does contain the word "cookie" in several places, it does not identify it as a specific concept to be legislated; rather, it is provided as an example (and thus the rest of my point remains applicable, and "not using cookies" will not magically remove the need for consent).

localStorage is how all applications built with a "Backend-as-a-Service" are made, because BaaS typically do not accept cookies...

This is irrelevant, and a problem of those services. That does not justify using JWT for sessions in your own application.

Are you suggesting that half-a-million developers using Google Firebase are doing it "wrong"...?

Aside from the fact that Firebase is extremely poorly engineered, this is an appeal to authority and has no place in a technical discussion. I'm not interested in discussing the decisions of a particular company for a particular product; I am only interested in discussing the merits and downsides of a given approach.

Stateless Sessions are possible with JWTs because they have a built-in exp (expiration time) option, however we chose/prefer not to make our sessions stateless instead opting to store a session id (jti) inside the JWT which gets looked up in a Redis store after the JWT has been verified. This means we can invalidate a session when a person logs out or if their device is stolen and they need to revoke an active session.

At which point there is no actual benefit to using JWT anymore. Why aren't you just using express-session or some other battle-tested, peer-reviewed session solution that fits into your stack? The recommendation for JWT makes no sense here, because people shouldn't be rolling their own session management in the first place.

Not to mention that session expiry should be handled server-side, and so the exp in your JWT is essentially useless.

Yes, the primary purpose of JWTs is to is to pass claims between parties in web application environment, that's exactly what we are using them for.

JWTs are not related to "web application environments" in the slightest.

Our sessions ids or tokens could simply be a random string which gets checked server-side, but we decided to use JWTs to format and sign the session data.

Again, just use a battle-tested session implementation for your stack. JWT is the wrong recommendation to make here.

We respectfully disagree that the content of these notes is "Dangerous".

You can disagree, but that's what it is. There are so many ways to use JWT wrong - several of which are alluded to by the README in this repository - that people are bound to shoot themselves in the foot. Yes, it's harmful.

@pscott-au: joepie91 - you clearly have a good undertanding of the issues .. could you provide some thoughts on what the real benefits of this kind of usage of JWT's really is?

There are no benefits in using JWT for standard web applications, unless you are running at Reddit scale. Some common examples of cases where JWTs are useful:

• Single Sign-On mechanisms (where the JWT is used as a one-time authentication token that the user exchanges for a session in the target application),
• Temporary access tokens for private images where the URLs are meant to be shareable,
• Basically any scenario where two systems that trust each other need to exchange a bit of data through an untrusted party, without being in direct contact with each other or sharing a backend.

For standard web application sessions, you should just use a well-tested session implementation for whatever stack you're using (eg. express-session when you're using Express).

[pscott-au]

It's great to have this discussion as it really challenges some of my experience. Perhaps some context for my personal interest in using JWT ( aside from the fact that I make use of Firebase which I would be interested in learning the poor engineering issues which I will look into ). When creating mobile apps/SPA and particularly when using services sourced from multiple servers/domains I find that I often require a single sign on capability that JWT seems to lend itself to nicely. My understanding is that the use of session cookies evolved over a period in which the security was tightened in the browser and JS space and the introduction of CORS evolved to handle exceptions to this leaving us with a rather hacky solution that JWT goes some way to address.
For years cookie session approaches have certainly afforded a much better approach than the original basic and digest http auth and there are many times when I would use a cookie session management solution for a web based app.
But .. I find that most apps I am now building are mobile or SPA and make heavy use of REST APIS. I like being able to test easily with simple curl requests without bundling the cookie handling stuff or dealing with multiple requests to establish the session. So I find that rapidly implementing APIs that things just work when I use JWT. In my gut it feels more appropriate to use JWT for long running sessions than cookies although I will ruminate on this as it may be laziness more than good intuition. I can extend the security along the lines of OAUTH if need be and I want to secure things more throughly but more often than not the session is not something that I judge as needing this level of security. The important thing to me is the flexibility that a JWT based authentication approach offers with regard to architectural changes in the future. I have found that older code has been refactored to provide JWT auth as an option and this introduced surprisingly little maintenance complexity but in most cases streamlined future development and I don't see any part of it as being inherently inferior to cookie sessions.
There are in fact advantages to using the JWT timeout features, particularly on mobile devices and some supporting libraries make use of this. You could for example have an app log the user out or leave them logged in based on this timeout when the device is not network connected.
For me I don't so much see any compelling argument about scale advantages of JWT over session cookies.
I see people suggesting that JWT can be used as a session cookie which to me does more harm than good as cookies have their own timeout period ( not entirely managed server side ) and combining these is likely to confuse.
Many modern JS frameworks are providing greater support for JWT than for cookies which suggests that the battle tested peer reviewed solution for the stack may in fact be tending toward JWT for many applications. While the popularity of JWT for web services is not a technical argument, dismissing this as irrelevant because they all such is equally fallacious. Express is not a core element the stack used by the dwyl group as best I can tell so there is no reason to align with it.
I hope that there is some thread of my intent that you can agree with as I remain concerned but not entirely convinced by your arguments.
I will agree that the README needs a serious overhaul and that there are lines that it pursues that are better removed or pushed back to a background discussion text and not in the main README.

[joepie91]

( aside from the fact that I make use of Firebase which I would be interested in learning the poor engineering issues which I will look into )

Some of the problems are that its JS client library is closed-source and obfuscated with rather unhelpful error output, there's no such thing as "arrays", there are many weird bugs in the client library where you might just not get back a response for unclear reasons, the ACL system uses a non-standard JSON variant that even their own editor doesn't support, the JS API requires to use a pseudo-event API rather than a normal callback API (but doesn't behave consistently), and so on.

When creating mobile apps/SPA and particularly when using services sourced from multiple servers/domains I find that I often require a single sign on capability that JWT seems to lend itself to nicely. My understanding is that the use of session cookies evolved over a period in which the security was tightened in the browser and JS space and the introduction of CORS evolved to handle exceptions to this leaving us with a rather hacky solution that JWT goes some way to address.

Not quite accurate. Your application and third-party APIs are different things, with different authentication requirements. Whereas a token-based authentication system can make sense in an application when talking to a third-party API, this doesn't make sense for your own application, even if it's an SPA. That's also unrelated to "single sign-on", which refers to multiple end-user services using the same login service.

CORS is a separate issue, and not really related to this.

But .. I find that most apps I am now building are mobile or SPA and make heavy use of REST APIS. I like being able to test easily with simple curl requests without bundling the cookie handling stuff or dealing with multiple requests to establish the session. So I find that rapidly implementing APIs that things just work when I use JWT.

In development, you might have certain testing requirements, but these shouldn't affect the approach you take in production. Aside from the fact that most things that are an SPA really shouldn't be an SPA to begin with (SPAs are for webapps, not websites!), there's no reason why you can't use sessions with them.

Aside from that, cURL supports cookies fine, and there are many other, better API testing clients like httpie or even http-prompt.

I can extend the security along the lines of OAUTH if need be and I want to secure things more throughly but more often than not the session is not something that I judge as needing this level of security.

The session is one of the most important aspects of your application. If it's not sufficiently secure, your application is essentially broken and completely vulnerable. That's why eg. storing JWTs in LocalStorage is a terrible idea.

The important thing to me is the flexibility that a JWT based authentication approach offers with regard to architectural changes in the future. I have found that older code has been refactored to provide JWT auth as an option and this introduced surprisingly little maintenance complexity but in most cases streamlined future development and I don't see any part of it as being inherently inferior to cookie sessions.

No flexibility is introduced here that 99.99% of developers will ever need, and I've already highlighted some of the problems it introduces, like stale data and inability to invalidate tokens.

There are in fact advantages to using the JWT timeout features, particularly on mobile devices and some supporting libraries make use of this. You could for example have an app log the user out or leave them logged in based on this timeout when the device is not network connected.

This is not unique to JWT; you can do this with server-side sessions just fine. In fact, JWTs cannot be invalidated without introducing (complex) stateful architecture, so sessions actually win out here.

For me I don't so much see any compelling argument about scale advantages of JWT over session cookies.

The scaling advantage is that you don't need a single canonical server holding all the sessions (since the data can be stored directly in the token), meaning you can remove a bottleneck. But as I said, almost no developer will ever run into this problem in practice. It's only useful for extremely large-scale projects.

Many modern JS frameworks are providing greater support for JWT than for cookies which suggests that the battle tested peer reviewed solution for the stack may in fact be tending toward JWT for many applications.

I have yet to see a framework that doesn't support session cookies.

Express is not a core element the stack used by the dwyl group as best I can tell so there is no reason to align with it.

That is their problem. Express was simply one example, well-tested session implementations exist for basically every commonly used framework.

The bottom line is that for any developer that is reading this repository, there are going to be precisely zero real-world advantages to JWT, and several drawbacks or even security issues. It's just not a sound technical choice or recommendation, and that is really the end of it.

[nelsonic]

@joepie91 I cannot tell you how delighted I am that you have found our repo/notes and invested your time to read it through and give us feedback! Seriously, if I ever meet you in person, I will give you a pallet of what ever it is you like to drink! 🍺

If I make you a contributor on this repo will you review my Pull Request for improving it? 📝

Also, @AshleyPinner, @alfiepates, @sunny-g how did you gentlemen stumble upon this particular discussion? was the issue shared on Redit/Hackernews? (I'm just curious how people find our posts...)

[pscott-au]

I have been chewing on this for a couple of days and just can't get on board with many of the arguments against using JWT as a default choice ahead of traditional session cookies in modern SPA and mobile apps.
I was thinking of constructing a decision matrix to weigh the pros and cons of cookies/JWT auth approaches for specific requirements, or detailing the pros and cons across a set of use cases before thinking about rewriting the README. It seems to me that many of the real-world challenges that people encounter in building complex apps are for the most part less elegantly solved or at least as problematic using cookie sessions. The perception that the issue poster creates is that JWT is some hacked together unreliable immature tech that is unsuitable for modern apps and this assertion is perhaps even more dangerous than providing a fully worked example of using it to authenticate a user.
I found This OATH article helpful. I think that one of the things that has triggered such a strong reaction to this repo but the issue reporter is the discussion of features that are typically expected in Cookie Sessions using JWT that detract from some of the core benefits of JWT, primarily involving that it can be stateless. Be introducing state by incorporating persistent storage we are eliminating one of the main use cases for JWT and re-implementing things that are mature using cookies.
That said, complex apps are prone to requiring some find of state - even if just for transactional requests for actions that are processed beyond the life of a single HTTP request. This should not preclude the use of JWT but should give us pause to consider what role the JWT plays in the transaction. I consider it OK to have a JWT that grants access to a resource and the resource has a state for the user that denies access to a service; in this case it is not the JWT that needs to be expired, but the state of the user accessing the service using the JWT.

Extending further to use cookies as the transport mechanism eliminates another of the benefits and brings us back to using cookies but ignoring the usual library functionality and rewriting features from scratch which introduces further ambiguity because we end up with duplicate timeouts etc. When I mentioned CORS earlier perhaps it was better to be explicit in pointing out the difficulties of using multiple domains with cookies. Sure, you can set wildcard domains, but if they are sufficiently different then traditional session cookies quickly become unwieldy. It can be argued that most developers don't need their authenticated client to access protected resources on multiple domains but this is becoming far more a common practice rather than an exotic edge case.
In a sense as a new person starting to explore management of authenticated sessions I appreciate that this may not be an appropriate way to learn about how to limit access to a resource in a web app to authenticated users in the simplest sense, but the use of JWT is only going to become more prominent as the starting point for authenticated sessions so to dismiss this because we have used session cookies for a long time is not enough for me to believe that everyone should start with session cookies and only learn about and use JWT when they find that they are unable to share cookies across domains or need to access a 3rd party API or need to be able to determine the expiry without checking the server, or question the storage of the user login credentials on the mobile device etc etc etc.

To understate the advantages of stateless tokens as something that is irrelevant unless you are running a top tier trafficked site is incorrect. Even when we kludge things up by introducing a new layer of state, the decoupling of the session from the server has numerous advantages.

[joepie91]

@nelsonic Looking at 4744cd1, that seems like much clearer wording. The header doesn't seem to reflect the changes, though.

@pscott-au: in modern SPA and mobile apps.

This is completely orthogonal to your choice of session mechanism. Not to mention that most things that are an SPA today, shouldn't be. Using an SPA for a website (as opposed to a web-app) breaks the web.

It seems to me that many of the real-world challenges that people encounter in building complex apps are for the most part less elegantly solved or at least as problematic using cookie sessions.

Such as?

The perception that the issue poster creates is that JWT is some hacked together unreliable immature tech that is unsuitable for modern apps

No, it isn't. JWT as a technology is not terrible (even if there are some questionable decisions in the specification) - sessions are just not its intended purpose, and it's a poor fit for that usecase.

I'm not saying that the tool is bad, I'm saying that you're using it wrong.

and this assertion is perhaps even more dangerous than

What is your rationale for that?

I found This OATH article helpful.

Addressing it point by point:

• Stateless, Scalable and Decoupled: I have already acknowledged that this is a theoretical benefit, but one that in practice almost nobody actually needs. You should also consider that Auth0 has a vested interest here, one that does not benefit you as a developer: "Third party services such as Auth0 can handle the issuing of tokens and then the server only needs to verify the validity of the token." Outsourcing your authentication is a terrible idea, by the way.
• Cross Domain and CORS: Complete and utter nonsense. This talks about the storage method, which is entirely separate from whether the token contains the session data or not. You can have a session ID sent along manually, or you could store a JWT in a cookie. Has nothing to do with JWT vs. sessions - which also shows the bias/ignorance of the article author, as comparing "cookies vs. tokens" doesn't make any sense to begin with. It also completely ignores this security issue.
• Store Data in the JWT: Not a feature. Same applies to sessions. And cookies, by the way.
• Performance: This is just a repetition of the "stateless" point, mostly - aside from the fact that it is not at all clear whether cryptographical verification can necessarily beat something like Redis on session data handling performance (their comparison to an RDBMS is unrealistic), it's also a completely insignificant performance optimization for almost every web-app. This is called "premature optimization", and it is widely recommended against for very good reason.
• Mobile Ready: Nonsense. If your HTTP library doesn't support cookies, look for a better HTTP library. Cookies are supported just fine, they're just HTTP headers.

So no, that article doesn't bring in any new benefits of JWT that I haven't already covered. It just misrepresents the sometimes-a-benefit (statelessness) as something that applies to every application (it doesn't), and then makes nonsensical comparisons and overemphasizes session performance for the remainder.

I think that one of the things that has triggered such a strong reaction to this repo but the issue reporter is the discussion of features that are typically expected in Cookie Sessions using JWT that detract from some of the core benefits of JWT, primarily involving that it can be stateless.

As I've said, this is almost never a benefit in practice. You can keep repeating this same point of statelessness over and over again, but it will not make it any more valid or applicable. It is absolutely not a general-purpose requirement.

I consider it OK to have a JWT that grants access to a resource and the resource has a state for the user that denies access to a service; in this case it is not the JWT that needs to be expired, but the state of the user accessing the service using the JWT.

In which case you have precisely no benefits over a regular session ID of some sort.

[...] When I mentioned CORS earlier perhaps it was better to be explicit in pointing out the difficulties of using multiple domains with cookies. Sure, you can set wildcard domains, but if they are sufficiently different then traditional session cookies quickly become unwieldy.

This is, also, completely orthogonal to the point. This is purely about where you store your identifiers, not about whether they contain the session data by themselves. And again, security risk.

but the use of JWT is only going to become more prominent as the starting point for authenticated sessions

And that concerns me greatly, because that prominent use is based on ignorance and hype, and comes with many security problems. This is a major step back.

so to dismiss this because we have used session cookies for a long time

I never said anything of the sort. I've provided several very clear reasons as to why JWT is objectively inferior for session management.

and only learn about and use JWT when they find that they are unable to share cookies across domains

In which case, security problem. Cookies are not optional.

or need to access a 3rd party API

Irrelevant to sessions.

or need to be able to determine the expiry without checking the server

Not possible, because the server needs to retain the ability to explicitly invalidate a session - eg. when the user changes their password or forcibly closes other sessions.

or question the storage of the user login credentials on the mobile device etc etc etc.

Cookies. Done.

To understate the advantages of stateless tokens as something that is irrelevant unless you are running a top tier trafficked site is incorrect. Even when we kludge things up by introducing a new layer of state, the decoupling of the session from the server has numerous advantages.

Yet you mention none of them that I haven't already addressed, and taken into account in my conclusions. I'm sorry, but you're defending novel approaches for the sake of being novel approaches, and completely ignoring the objective, technical properties of the different approaches.

That's what is called "hype", and it's extremely harmful.

[joepie91]

Stateless: important when an app needs to function offline and retain some kind of meaning.

Offline applications don't need authentication, at all. There's, by definition, no interaction with other systems.

Cross Domain Credential Auth: Important if you split your application into microservices using multiple servers

Correct. But in this case, you don't use JWT as your session mechanism, you use it as a single-use token that can be exchanged for a session. There's a very big difference between the two, and the tradeoffs it presents.

(EDIT: Of course this assumes stateful microservices, and with 'stateful' I am not referring to the session, but to the service itself. For microservices that carry out stateless tasks, single-use tokens without using a session at all is sufficient, with the single-use tokens being issued by the application server. For application servers talking to microservices, JWT is fine as well - there's no concept of a "session" here, and token revocation can be done by changing the signing key.)

You can continue to deny the usefullness of JWT

Again, I am not doing any such thing. These are entirely your words.

When I try to provide more detail you just dismiss my cases as irrelevant or bad practice .. in my opinion incorrectly so.

Then I expect you to elaborate on why it is incorrect, not just say "that's incorrect!" and expect me to take it at face value. I'm concretely addressing every point you provide for precisely this reason.

Relying on a cookie to manage an iOS login session is not the best solution by default.

Why?

cookies can be misused

That's an empty statement. Misused how? And how does this not apply to values stored in Local Storage? And what does this even have to do with JWT at all given that "cookies" is a storage method, not a session mechanism? Comparing "JWT vs. cookies" is comparing apples and oranges, they aren't even the same class of thing!

The use of JWT for session management is different and has different properties than cookie sessions - this does not make it inferior but simply has different operating parameter criteria in architecting an appropriate solution. If you want to use cookies use cookies - if they meet your requirements use them - why do you want to prevent other people from considering any other approach?

I'm not. I have very clearly indicated exceptions where JWT is the right solution. I have also very clearly indicated that JWT is unsuitable as a general purpose session mechanism. Stop putting words in my mouth.

You notion of login sessions as being of value only to authenticate against your web server with persistent storage ignores the fact that I may well want to have some data services provided by alternative providers that van validate the same JWT and not require new cookies to be created. In what way is this irrelevant to sessions???

Because there's no reason you cannot use both JWT and sessions, for different purposes. Trying to shoehorn it all into a single mechanism for the sake of it, is completely misguided. Use the tool that is appropriate - "not require new cookies to be created" is a completely arbitrary metric and realistically, not the benefit you are implying it to be.

If you see security problems then identify them and flag them - they may not be a show stopper but may be useful to be aware of in making the decision. You vitriolic wording doesn't acknowledge this or even consider this a possibility because you continue to state that session cookies should be used for every http app which is just ridiculous.

Again. Not. What. I. Said. Stop putting words into my mouth.

The examples you cited of the role of sessions to enforce specific rules such as terminating on password changes or to manage service restrictions is not an in-built function of session cookies, just a function that is typically utilised by this approach.

It's a feature that requires stateful sessions of some sort, architecturally. I'm not arguing that this is provided by session cookies - I'm arguing that it is impossible with stateless tokens.

If you solution is quite comfortable to provide authenticated access without checking a db to access a resource for the life of the session then why do you insist that this is a failure of this approach.

Again, not what I said.

When we suggest that the specific controls ( should they require some kind of terminatable session ) could be introduced as required you respond that cookies have this built in that you should never try to look at other approaches. Implementing this kind of control is not of such a significant overhead as to preclude JWT auth sessions over cookies.

The point isn't overhead. The point is using tried and tested solutions that are known to work well. Reimplementing your own security is a terrible idea in any situation, and that includes this one.

You ignore the number of requests for cookies and suggest that the only performance consideration is the lookup. The need to coordinate refreshes etc and depend on .. oh never mind... (gave up here)

What are you even talking about? Cookie "refreshes" are handled inline in HTTP responses by sending along a new cookie - there's nothing extra involved here aside from updating the session store, which I've already covered in my Redis example. If you think there are other performance considerations, then list them.

You may love that cookies are restricted to domains and consider that allowing them to be used cross-domains introduces security problems that preclude their use - that is fine - I do not.

Again, not what I said.

JWT are not the next thing to replace all session cookies but neither are they as serious an abomination ( when used to manage sessions ) as you indicate.

Yes, they are. The only reason you would ever want to use JWT for sessions is because the alternatives are worse or impossible, and that is an extremely rare edge case.

You treat security as an absolute with no mention of the various refinements that could be made to this approach if/when required and how the complexity of that evolution compares with traditional session based approaches.

I'm only treating security as an absolute when it is an absolute. I've also addressed possible ways to solve it, and explained how they are not a good solution as compared to sessions because the net result is still worse. If you think there is a case or solution I'm missing, then mention it. Stop vaguely alluding to "other options" without ever actually explaining what they are. Right now, as far as I can tell, you are bluffing.

Not hype - not based on ignorance but is a valid solution to problems regularly faced when building hybrid apps that require cross authentication for services that are not aiming to provide the absolute tightest security that technology can offer and for good reason - very practical - very broadly adopted - does not make everything turn to crap.

Repeating your assertion doesn't make it any more true. I've already covered why this is false, and compromising on security for hype reasons is not acceptable.

For some of us having the flexibility to control the session with finer granularity than provided by cookies affords greater flexibility - if you don't see the use cases then fine - I expect that if you build many hybrid apps that you will and perhaps then you will be able to better articulate the counterarguments to some of the points you present than I.

There is no "greater flexibility". Again, if you think there is, explain how.

Anyway - you are far more eloquent then me and are clearly unshakable in your position

No. I just expect somebody to provide solid, well-argued, technically correct arguments, if they wish to change my views. You have not done so.

I remember the last time I had such an unrelenting attachment to an approach was when someone was arguing that digest auth should never be replaced with session cookies.

... and that would be a perfect example of such a fallacy.

---

The bottom line is that half your statements are putting words in my mouth that I have never uttered, nor implied, nor intended. The other half argues for unnecessary compromise in security, or makes hand-wavy claims about there being "other benefits" or "other solutions" without ever going into it any further.

Frankly, I'm tired of this - I don't think this discussion is going to go in a constructive direction, and it's muddying up the thread. The only reason I keep responding, is because of the risk of people being misinformed by your non-arguments.

If you want to keep believing that JWT is the holy grail despite having no technical arguments to support that notion, then that's your choice - but you will not convince me unless you come up with actual technical arguments, and continuing to repeat the same assertions over and over again is not going to help anybody.

---

To summarize my points for those skimming over the entire discussion:

• JWT is not designed for sessions, but for transferring signed claims, usually single-use.
• JWT is unsuitable for sessions, because of the inability to invalidate tokens, problems with stale data, and the need to write untested implementations to make it work. These are security issues.
• "Cookies vs. JWT" is not a valid comparison; one is a storage mechanism while the other is a token format. Cookies are not optional, regardless of whether you are using JWT or not. Storing any kind of token outside of a cookie is a security issue.
• Sometimes you can't use stateful sessions because you are operating at a very large scale, and in those cases JWT can be the 'least bad' option available - but these cases are rare, and unless you work for a major site the size of Reddit, you will likely never run into them.

(Reddit uses stateful sessions, by the way.)

[pscott-au]

I believe that the intent of this repo is to pave the way for implementation of a mobile hybrid SPA and the use of JWT as a replacement for cookie sessions is a common and almost standard approach.
One of the drivers for this is the issue that cookies have in being bound to a domain when an SPA may in fact require access to micro-services across multiple domains on different platforms. JWT is a neat approach to the limitations of cookies in this context. Using an OAUTH or OAUTH2 approach would be more robust from a security point of view but introduces complexity that may not be required for many applications. JWT bearer sessions that do not depend on negotiating an AUTH token is not a misuse of JWT but an application of a less secure approach in order to gain simplicity and for applications that have more to gain from rapid implementation than the added security provided by a more robust approach. At the same time as streamlining rapid implementation it provides a clearer migration path to single use tokens then other approaches.
Some of the backlash and vitriol against the use of JWT Bearer token headers as a replacement for session cookies is indeed based on some people presenting them as an evolution or improvement over cookies more broadly which I agree is not the case. I ask you to consider so of my use cases and how you would approach them using cookies.
using JWT for auth session management should be done with care and the deficiencies should be made explicit however dismissing them as useless hype being always used out of context is misleading and incorrect.
Using JWT means that you don't need to refresh cookies every time you the client contacts the server. Reasonable confidence can be assured without checking the database although it is just as easy to extend this check as it is using session cookies.
Using JWT means that clients with cookies blocked will not be forced to fall back to using hidden post variables etc as a backfill.
Using JWT across multiple services allows a service that doesn't require auth but wants some indication of the validity of a simple data field such as uid which can be wrapped into a JWT and passed.
JWT approaches lend themselves to more sophisticated OAUTH approaches.
JWT REST requests can be made without posting credentials or requiring a request for a cookie before accessing the service which can simplify REST/SPA implementation.
Using a bearer header or a cookie header is not dramatically different when it comes to security ( except for domain restrictions which may validly be undesirable. (NB I am not putting words in your mouth but trying to interpret what you are alluding to by saying that the security is worse)
Where prolonged periods of absence are common/expected such as with mobile applications, cookies may be less desirable than a JWT approach. Having a clearer path to self examination of credentials can facilitate behaviour without checking in with the server.
If you accept that there are use cases for sessions that may have prolonged offline periods then sessions are not necessarily stateful.
If you are able to accept that sessions can successfully exist with multiple states from perspective of the client and the server then perhaps you can draw closer to use cases that include periods of prolonged non-connectivity with the server ( eg collecting user data for batch update on reconnect ). There are cases where the client could operate more effectively knowing that the session has expired and a refresh is required without managing another layer of data. Also being able to use the JWT as a session validation even after the password has changed etc can be useful in some cases to allow the data to be passed to the business logic layer and have that decide how to accept the request.
You keep telling me that cookies are secure which I assume to allude to the implementation in browsers etc - outside a browser I fail to see why they are inherently more secure - perhaps you can elaborate?
In SPA/Hybrid apps the reliance on cookies is not necessarily the only starting position - relying on cookie handling by the browser does not bring you closer to native but introduces a dependence on the UIWebView or whatever and I do not remain confident that it will always behave as I expect.
Tokens can be retained in memory for the execution life of an app without necessarily being persisted - this is not really the same thing as relying on the integrity of cookies - there is more granular control in iOS at least on storage permissions that exist beyond the browser and this strikes me as more appropriate than being bound to browser storage approaches.
Cookies are indeed optional - there is no law stating that you must only use cookies.
The decoupling of the session from the server may in some cases be a bad thing but not always - modern approaches including the use of JWT introduce new concerns but also new flexibility and this flexibility does not just include least bad approaches.

To summarise my position:
The use of JWT as part of a auth session solution is not always trumped by session cookies
JWT is suitable for session if you are aware of the benefits and have a reason not to require simplistic invalidation.
Cookies are not the only solution.
Large scale is not the only use case for stateless session - using JWT headers to authenticate across domains/services is a valid reason for using them as an alternative to session cookies.

[joepie91]

I ask you to consider so of my use cases and how you would approach them using cookies.

Sure.

Using JWT means that you don't need to refresh cookies every time you the client contacts the server.

This is the same for session cookies, JWT-containing cookies, and JWT tokens themselves - you only need to explicitly 'refresh' them if they are about to expire. There's no difference here.

Using JWT means that clients with cookies blocked will not be forced to fall back to using hidden post variables etc as a backfill.

Users that block cookies will almost certainly also block Local Storage and other persistence measures (for precisely the same reason they block cookies). Privacy extensions do the same. Again, "JWT vs. cookies" is not a valid comparison, and if a user blocks cookies, then you will not be able to persist a token anyway. JWT or not, doesn't matter.

(If a user blocks cookies wholesale, they already choose not to have data persistence anyway, so trying to support authentication for cookie-blocking users is a bit of a lost cause. That's the tradeoff that comes with it, and it's a completely technically reasonable tradeoff.)

Using JWT across multiple services allows a service that doesn't require auth but wants some indication of the validity of a simple data field such as uid which can be wrapped into a JWT and passed.

See the edit of my previous post (third paragraph), which addresses single-use tokens in distributed architectures. These aren't sessions nor should they be persistent, so the issues I've described don't apply there.

JWT approaches lend themselves to more sophisticated OAUTH approaches.

OAuth makes use of single-use tokens. It's not a replacement for sessions. Again, see the edit of my previous post.

JWT REST requests can be made without posting credentials or requiring a request for a cookie before accessing the service which can simplify REST/SPA implementation.

They can't. You still need to obtain a JWT somehow, which means it needs to be issued by the server, which means you need to ask the server for it. Whether the server returns a cookie or a different header or value doesn't matter. And again, "cookies vs. JWT" is not a valid comparison.

Using a bearer header or a cookie header is not dramatically different when it comes to security ( except for domain restrictions which may validly be undesirable.

Not seeing an argument here.

Where prolonged periods of absence are common/expected such as with mobile applications, cookies may be less desirable than a JWT approach. Having a clearer path to self examination of credentials can facilitate behaviour without checking in with the server.

This is a non-benefit - you don't need the token until you intend to communicate with a server anyway, so you can just attempt to make a request and deal with the 403 when it happens. Trying to avoid asking the server for something that inherently involves talking to a server (namely, making an authenticated request) doesn't make sense.

Not to mention that, if you want to know ahead of time whether your session will have expired, you can just send a separate cookie for this. Since it's just a UX hint for the application, you don't even need to verify its authenticity - and you need to deal with unexpected authentication failures anyway due to clock skew and changed signing keys.

In SPA/Hybrid apps the reliance on cookies is not necessarily the only starting position - relying on cookie handling by the browser does not bring you closer to native but introduces a dependence on the UIWebView or whatever and I do not remain confident that it will always behave as I expect.

It doesn't. Any reasonable HTTP library - browser or not - will support cookies. Cookies are by no means exclusive to browsers, they're a HTTP feature like any other.

The decoupling of the session from the server may in some cases be a bad thing but not always - modern approaches including the use of JWT introduce new concerns but also new flexibility and this flexibility does not just include least bad approaches.

I still haven't seen any concrete examples of such 'flexibility'.

The use of JWT as part of a session solution is not always trumped by session cookies

That's a very ambiguous statement. You're comparing using JWT as part of the solution, to using session cookies as the entire solution. These are not opposites - many complex architectures will require a combination of both session cookies and single-use JWT tokens, for example for SSO systems or distributed architectures.

JWT is suitable for session if you are aware of the benefits and have a reason not to require simplistic invalidation.

No. JWT tokens are a last resort when you cannot meet the requirements with session cookies.

Cookies are not the only solution.

Technically correct.

Large scale is not the only use case for stateless session.

It is the only usecase that I am aware of, and I have not seen any other valid ones mentioned throughout this thread. Mind that I am talking specifically about stateless sessions, not about stateless tokens in general.

[pscott-au]

I ask you this - how do I deploy an application that uses 3 different services ( perhaps on different container infrastructure etc ) and integrate them into the app relying on session cookies? If I setup an auth service and wish to decouple it from another service is the best approach to run a shared proxying cookie session handler? Is this an edge case?
How do cookies provide me with greater security, flexibility, standards compliance than using a long-running JWT to track my session. Assuming that I do not want or care about being able to terminate the session on demand (although that isn't exactly an inherent benefit of cookies but rather in the handling of requests), that I am using Bearer header with every post and responding to failure with an auth prompt/post to obtain a session JWT to be included in all headers - I may be stupid but I just don't see how this is any less secure? The cookie details are as available in the hybrid app as are the token although there is less control over the persistence ... I guess I just don't get why this is such a bad approach. Sure you need to provide credentials to obtain the JWT but you do it once - not on each service.

[joepie91]

I ask you this - how do I deploy an application that uses 3 different services ( perhaps on different container infrastructure etc ) and integrate them into the app relying on session cookies?

Depends on what the 3 services do. Can you elaborate?

If I setup an auth service and wish to decouple it from another service is the best approach to run a shared proxying cookie session handler? Is this an edge case?

You'd have the auth service issue a single-use JWT token indicating successful authentication, optionally including 'profile information' for the user, depending on your architecture. Then, depending on the application:

1. If a regular website: The auth service redirects to an authentication page on the application server, eg. passing the JWT token as a query parameter. The application server validates the token, and gives the user a session cookie.
2. If an SPA: The auth service returns the generated token in its (JSON?) response. The frontend application makes a HTTP request to the application server's authentication endpoint, including the token as a parameter, and after validation by the application server, receives a session cookie in exchange.
3. If a standalone application (desktop or mobile): Like for an SPA, but using a HTTP library that supports cookies, rather than a frontend application in a browser.

In both cases, the JWT token will only be valid for something like 5 minutes (to account for clock skew), and used once - to exchange it for a session on the application server. If you include profile information in the token, the authentication service remains completely decoupled from the application.

EDIT: Added standalone application case.

[pscott-au]

Lets assume we are in SPA / Hybrid mobile app development scenario. Also assume that we are just using JWT for session - not OUATH with auth and bearer tokens - just login and receive bearer token.
Lets imagine that we have a real time application with each session making requests to all 3 services every 5-15 secs. Many users logging in for quick status check or to post GIS data or something so average usage time is less than 1 minute but wish to start app - close it - restart 3 days later without credentials etc. ( adding detail that is largely irrelevant here but things that would tend me away from cookies )

As an example lets say I've created an AWS service with a graph query service, a mapping or GIS service on a docker rackspace and a REST interface to postgres db to manage user profile data. I can use the same JWT in header requests to all REST services and validate against a common secret to have shared validation from the JWT issued once.
Lets assume that they are stateful within their own context but only loosely in a shared context.
These are problem specifications that match my proposed solution using JWT as a session token as a Bearer Token and given a similar environment I am asking how you would approach using session cookies so that we can compare.

Lets say they all require reasonable confidence that the user is who they say they are.
My solution would be to generate a JWT token in response to credential post that is used across all services within the HTTP header to authenticate - with the validation being done with the shared JWT secret across all the services.
The auth service generates the token and returns it on login. The token is included in header requests to all other services on different domains. If using cookies we need to establish new cookies for each domain. Why would I want the services making new requests to validate or obtain a cookie for each http received when I can confidently depend on the JWT? If I have 5 services I now need to be managing 5 different session cookies and ensuring the coordination between all of these. In many cases this could be the right approach but in many it strikes me as overly complex for something that is quick and simple to implement and does not expose serious security holes that I can clearly see.
Why limit the JWT timeframe? Cookies are traditionally short lived because they assume regular server contact - what if I don't want to expire quickly but am happy to have stale sessions running long-lived because I decide that the trade-off of re-authenticating is a greater risk.

If I understand correctly in your situation I've got 9 requests bouncing around every period instead of 3. I've got an auth server being wacked to confirm established sessions. I've got more code and more moving parts. I get the advantage of being able to terminate the sessions each period but what if that isn't a requirement. What if I don't care about receiving posted data for another 48 hours after the user has been terminated and using the auth server for new requests I can still filter out what I don't need?

In this use case, minor time skew is irrelevant because of the session granularity being set appropriately and as with session cookies I would implement the client refreshing the JWT through the auth server in the appropriate timeout period. As far as 'profile' goes lets just stick with a share uid as the common id ( if I understand correctly ) and the server side implementations contain a shared secret for signing/validating the JWT.

In my proposed architecture I do not need to revoke the tokens at a finer granularity than provided by the JWT timeout so why should I use session cookies instead?
In my proposed architecture you could create dependencies between the states of the services but you could architect this rather than depending on it being centralised and needing to bridge everything back to the auth by default. The key is flexibility - and it comes at the cost of realising the dependencies but this is in your face from the beginning and not a layer over something that although implemented on all platforms is handled differently across frameworks. It may be non-trivial to update the cookie expiry for a session with node,php and exotic cookie session default handling without actually and so you may be encouraged to just post an auth server request directly so not only are we firing off 3 x the requests but there are 3x the requests for the client.

If I align with your proposed architecture then I indeed need to grapple with the timeouts across multiple cookies. As an example if the client logs in and receives an auth'd session cookie that expires in 1 hr
and then 40 minutes later they post this session cookie value to our first service which then queries the auth server before issuing a local domain cookie, do we hack the internal original auth cookie expiry or do we set a timeout on the service cookie to 20 minutes and when this expires trigger a refresh of the auth cookie. Unless I'm missing an obvious solution this can easily turn into a big pile of spagetti that could be entirely avoided by using a single JWT with a single ttl that could be refresh through either any of the services ( understanding how this possibly extends the token life ) or by requiring a refresh through the auth server.

I could discuss approaches to stale data but the problem scope in this use case does not rely on invalidating stale credentials ( from perspective of the auth server ) so this would not be relevant.

It is my understanding is that we are discussing your assertion that using JWT as an authenticated session management approach is inherently inferior and incorrect versus the use of session cookies as an authenticated session management approach for cross domain services within a hybrid mobile application to be run on devices intermittently without resupply of credentials.

I am trying to ascertain whether you would argue that the proposed approach is inherently less secure or less 'correct' in any way. As I see it there are significant advantages in the simplicity of this architecture and no advantages offered by the heavier more complex solution required to manage sessions across all the services that have not been accounted for and traded off for the simpler architecture. If you could point out how this solution would experience problems not experienced using cookies to manage sessions then it would really help me to underdtand those explicitly ( ie how is the security compromised )

[joepie91]

The services almost don't matter - not sure what you are alluding to?

There's a difference between stateful and stateless services.

Lets say [...]

This is describing how you'd solve the problem, not what the problem is. It's not useful when asking me to explain how to approach it with sessions, because it already assumes that you won't be using sessions. Describe the problem instead.

when I can confidently depend on the JWT?

You can't.

If I have 5 services I now need to be managing 5 different session cookies and ensuring the coordination between all of these.

Unlikely. See my remark about stateful vs. stateless services.

In many cases this could be the right approach but in many it strikes me as overly complex for something that is quick and simple to implement and does not expose serious security holes that I can clearly see.

Authentication and session management, especially in distributed architectures, is complex. There's a reason engineers have avoided distributed architectures wherever possible in the past. "Just use JWT" glosses over this and pretends it's easier than it really is, by completely ignoring data staleness and session invalidation.

The security holes are there, and I've made several attempts at explaining them - that you can't clearly see them is not something I can do anything about, if you don't ask specific questions about the parts that are unclear to you.

Why limit the JWT timeframe?

In the example I gave? Because they are intended as single-use exchange tokens, not persistent identifiers. You don't want them to be persistent identifiers, because you can't revoke them.

Cookies are traditionally short lived because they assume regular server contact - what if I don't want to expire quickly but am happy to have stale sessions running long-lived because I decide that the trade-off of re-authenticating is a greater risk.

There's no risk in refreshing a session.

ignore profile or clock skew - details that don't have a huge impact on our discussion in this hypothetical as same issues apply if using cookies for similar scenario.

They are just as important a part of a robust authentication system as all the other points mentioned. Ignoring them is not an option. And again, this is not about "cookies", this is about sessions.

For sessions, no, the same issues do not apply; a centralized/stateful session store means data doesn't go stale at all and profile information can be retrieved at any point, and clock skew is an issue for any limited-validity tokens that are exchanged between different systems.

[pscott-au]

It looks as though we could summarise your objection to JWT as a session management approach could come down to you attachment to a definition of sessions that requires revocation per request (and a few other features that have traditionally been part of ensuring that a user is authorised to access) and the danger associated in refreshing them (if they are intercepted) . Distributed processing is the new norm - multiple services is very common - if we are to adopt the use of this kind of approach to multi-service architecture then we need to fully understand the consequences. Distributed databases have existed for a long time. Distributed data stores such as DNS have existing since the beginning. Sometimes the simplicity of the architecture affords more benefits than trying to squeeze the existing dominant standard beyond its design limits. If we are aware of the transactional ACID issues in our service request sessions then there is no reason we shouldn't embrace a JWT session management approach to authenticat services to fully exploit the possibilities without being constrained by what quickly becomes a complex infrastructure if we insist on hard constraints and try to shoe-horn session cookies as the solution that is superior.
@joepie91 - where appropriate you could well use cookie session auth for the primary auth and require this to refresh the JWT. Again - the use of JWT for cross domain session service access can be used as part of the solution and cookie session used also if appropriate. The point is that JWT as part of session management - even for accessing a subset of services - is not I believe an evil approach that has no role.
https session cookies also come with risks - it is surprising how many sites have the ssl flag unset and pass the cookie as plaintext over when communicating SSL. Does this make cookie sessions dangerous?
The biggest risk that I seem to be able to find is that the coder allows the token to be sent to the wrong server and that the token effectively allows a 3rd party to access these secondary user resources. This should be flagged in big red letters somewhere and places a strong onus on the developer to ensure that this doesn't happen. The developer should take appropriate steps to ensure that the necessary security measures have been taken and a repo such as this should explain some of these approaches and include them in examples. In my mind this is an acceptable price to pay for the flexibility of cross domain time limited service authentication to non-critical services.
In architecting a complex solution it is likely to include session cookies at the auth end and may be extended to include once-off tokens etc where appropriate. The point is that this stuff is possible and while there are places that it can go wrong and expose risks it provides the opportunity to build richer and leaner applications in many cases and for this reason I do not believe that this repo should be binned as suggested by the issue logger.
The inclination to try to get the best of both worlds by using JWT as the session string to me seems to introduce issues - most strikingly the possibly conflicting timeout/TTL periods. It also enforces the same domain access restrictions that we may have been trying to avoid in the first place so putting that in the basic example may well lead people to ask why use JWT in the first place?

The use of JS as a dependency is pretty minor - in the context of hybrid mobile SPA it is unlikely you are needing to accomodate a JS free client. Suggesting that this is an issue whilst similarly claiming that redis provides an efficient option for session storage seems a little contradictory.
The expiry in the JWT is not useless in that it provides a session timeout that must be handled either by refreshing ( in exactly the way that cookie sessions are refreshed ) or require re-authentication. Having the JWT signed ensures that it hasn't been tampered with and thus eliminates the absolute requirement for validating against persistent storage server-side although this can be done if desirable and achieves the same result as cookie sessions without as much opinionated implementation and with the ability to utilise cross domain if suitable. In a hybrid mobile app, storage of cookies or JWT in local storage again gives more control. Objections to the use of local storage over the security of browser implementation is a matter of trust in the vendor and acceptance of their handling of these credentials.
The flexibility is useful to many mobile hybrid SPA developers but requires an understanding of what the limitations are.
JWT can be invalidated by simply changing the signing key and again this affords flexibility - you may use a common shared private signing key across services or generate random per user session and realise the sort of repudiation benefits of session cookies.
Almost all modern JS frameworks support JWT and it would be difficult to find a major platform that doesn't - some however really probably shouldn't ( Wordpress JWT plugin .. hmm .. not looked at but makes me nervous ).
JWT usage should include background in OAUTH and the tradeoffs and benefits of using cookie sessions. To me there are real work advantages for average mobile hybrid developers using multiple services but there are traps that are easy to fall into. We may need many examples to fully illustrate.

[nelsonic]

My original reasoning for using a JWT as the Token for authorisation is that verifying a JWT is CPU-bound (my "old" laptop can verify 180k JWTs per second) by contrast if we were to use a simple token and have to look it up in memory (or a Database) the operation would be I/O-bound (or worse Network-bound) which would be considerably slower.
http://stackoverflow.com/questions/868568/what-do-the-terms-cpu-bound-and-i-o-bound-mean

Our Session management system first checks that the JWT is valid by verifying that it was signed using our key - and rejects a message early if it was not - and then checks if the session has not yet been invalidated (e.g. by the user logging out).

I know JWTs might not have been designed to be used as the tokens in Authorization headers, but I don't think I fully understand why it's a "bad idea" given that's faster than other session-management systems...

Note: I still agree that the "no cookies" angle is not the right way to start this readme/tutorial. 👍