Authentication for Modern Apps (and Why We’re Building Rune Auth)
Authentication is full of edge cases. Here’s why we’re building Rune Auth, what problems it’s meant to solve, and how we think about doing auth the pragmatic way.
Authentication is one of those areas where “it works on my machine” can turn into a security incident a month later.
You can absolutely build auth yourself—and sometimes you should—but most teams don’t need a custom identity system. They need a reliable, understandable foundation that doesn’t eat the roadmap.
That’s why we’re building Rune Authentication (Rune Auth).
Rune is unreleased and still in active development. This post is not a launch announcement—it’s the reasoning behind the product and the problems we’re targeting.
The problem with “just add login”
When people say “we need auth”, they usually mean a bundle of related problems:
- account creation and sign-in
- password resets and email verification
- sessions, refresh tokens, and device handling
- admin controls and auditability
- optional requirements like SSO and 2FA
- subscriptions, licensing, and access control (for paid products)
Each piece is manageable on its own. The pain comes from combining them, keeping them secure, and maintaining them for years.
What Rune Auth is (and isn’t)
Rune Auth is meant to be a developer-friendly authentication service you can integrate into an app without turning auth into your entire product.
It is not meant to be magic.
- If you have unusual regulatory constraints, strict on‑prem requirements, or bespoke security hardware, a tailored solution can be the right call.
- If you’re building a typical web app, SaaS, or desktop product with accounts, you probably want something opinionated, well‑designed, and boring (in the best way).
A quick vocabulary check (without the textbook)
Auth conversations get confusing because the same words get used differently. Here’s the practical meaning:
- OAuth 2.0: a standard for delegated access (authorization)
- OpenID Connect (OIDC): builds on OAuth 2.0 and standardizes sign-in (authentication)
- SSO: usually means signing in via an identity provider (social login or enterprise IdP)
- 2FA: an additional verification step that reduces account takeovers
You don’t need to memorize the specs to make good decisions—you just need to know what you’re integrating and what guarantees you expect.
What we’re trying to get right
Our approach with Rune is pragmatic:
- Clear defaults. Secure, predictable behavior out of the box.
- Integration that doesn’t fight you. SDKs/libraries so you’re not hand-rolling glue code.
- Admin and operations reality. Logs, management workflows, and the boring parts that keep systems healthy.
- Room to scale. Optional features like SSO/2FA should exist without making the basic setup painful.
What we plan Rune to cover
Because Rune is still unreleased, think of this as a direction rather than a promise of what you can use today.
The scope we’re working toward includes:
- User management (accounts, resets, verification)
- OAuth 2.0 / OIDC support for identity providers
- 2FA and SSO options for teams that need them
- Subscriptions and licensing for paid products
- Admin tooling and a predictable data model so it’s maintainable
If you’ve ever spent a week chasing “why is this token invalid only on mobile Safari”, you already understand why we care about getting the fundamentals right.
If you’re building a website or web app
Wavestorm builds software and games, and we also take on website projects on request. If you want a fast, SEO-friendly site (or a web app that needs a solid auth foundation), get in touch.
We’ll share more about Rune Auth as development progresses.