I'm the author of that article, as well as the somewhat popular tech talk I give about why JWTs suck and are stupid (all of which @joepie91 has eloquently written about much better than I ever could: http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/).
Given your application requirements (mobile app + JS front-end only app that both talk to a backend API), I'd suggest you use the OpenID Connect Authorization Code flow (w/ PKCE for your mobile app).
For your mobile app, specifically, I'd recommend using the fabulous AppAuth library: https://appauth.io/ (it has great libraries for both iOS + Android).
Now, you might be wondering why I'd recommend using OpenID Connect (and thus, JWTs) for something when I so publicly rally people against using JWTs: I'll tell you -- for most stuff it just does not matter.
Here's the thing: yes, JWTs are pretty awful to use when building secure apps. They're complicated, most libraries currently aren't spec complete, and using more advanced features like JWT encryption are almost sure to cause you massive headaches and compatibility issues between your services.
Furthermore, the entire reason JWTs have become popular for authentication is that they are frequently used to CACHE authentication and authorization data -- this entire practice is a big NO NO in the security world.
Caching sensitive data (like authentication and authorization data) is the worst possible thing you can ever do for security: you're trusting outdated information. ALL current auth systems built on top of JWTs suffer from this naïvety.
Once you've gone down the rabbit hole of trying to "speed up" your site/API by using JWTs, you've already committed a security sin and are now at risk.
Moreover, once people start using JWTs and realize they're at risk, they try to re-centralize everything (as one other commenter has suggested) and begin using revocation lists so that they can revoke tokens when bad things happen. This results in the same speed penalties as traditional session management, but with greater speed penalties due to JWTs being "heavier" than session cookies, and more fragile.
Sorry for the rant, but here's my advice:
- If you want real security, you have to use server-side sessions. In your case, this would entail supporting session cookies from your API backend so that when your react app authenticates to your API, the API sets a secure cookie that the react app uses automatically each time it talks back to the API service to authenticate. You'd also need to use a cookie-based API from your mobile app (I'm not familiar with building native mobile apps, so can't comment on this component).
- If you want simplicity and the same amount of security as just about every other major web app, using OIDC and go with out of the box open source solutions. This is the simplest way go currently and while it's not perfect, if it solves your problem then it likely isn't a big deal.
If you're building something sensitive, try to use server-side session cookies when possible. Otherwise? Don't sweat the details and go with the flow.