#war-on-state
I’ve been spending some of the Coronatime working on side projects, and recently got the chance to build something new to handle user auth in a stateless way.
Postgraphile is an open source way to quickly standup a full stack app, and having noticed people asking for refresh_token support, and seen plenty of sometimes acrimonious debate on the merits of traditional session vs JWT-based auth, I thought to myself, ‘self, enough opinions. Let’s build stateless auth ourselves & see what all the fuss is about!’
So, this is the result of my path to building so-called ‘stateless sessions’ and trying to make my progress transparent by open sourcing. I take no position on if you should use this, but it’s been working well for my needs. Especially if you need to perform a cloud native/microservice-style deployment, going stateless may be particularly attractive.
A lot of attention has gone into the details on this to arrange what I’d consider an appropriate balance of security and convenience, and maybe, just maybe, my parameters overlap with yours.
If you:
- need to authenticate incoming HTTP requests but don’t want to hit your database/Redis every time
- are willing to trade
access_tokenfetches in return for tokens living 100% in the user agent, perhaps because you - don’t want to maintain your own Redis instance
- prefer a frontend that avoids storing tokens in local storage
- tolerate
access_tokenlifetimes of 15 minutes (configurable) - prefer to use
HttpOnly,SecureandSameSiteflags - otherwise care about modern security best practices
…then this project, which aims to adopt a “strong but stateless” auth stance, may be interesting.
Check it out
Prefer Apollo Server? I’ve got you covered too.
If enough people like this I’ll consider publishing to NPM. Until then I’d be curious to know what you think!
Thanks to the clever people who came before me, including contributors to the OAuth spec, Ben Awad, @newsiberian for accepting my PR.
Assuming you speak JavaScript, for your next MVP or hackathon you could choose worse to start with, just saying :)