The circumstances are immaterial; if the creators of a system are blasé enough to imagine you’ll neither need nor want to manage or query the underlying data storage, then they’re telegraphing naiveté and inexperience. Capacity, throughput, latency, consistency concerns exist in any nontrivial system and the pointy end/bottleneck of these is very often at the level of persistence. Auth services can add privacy and integrity to that pile. And so on. Consequently, glossing over it with a handwave is a bright red flag.

99% of the time is a rather high rate of failure .. 1% of a year is still over 3 days. 1% of a million is still a lot of incidents

Thanks for sharing!

I agree that passkeys would solve all that, but they have their own set of problems (mainly being bound to a device) and they are still very far from being universally adopted.

I’m looking forward to OAuth2.1 - at the moment it is still in draft stage, so it will take a couple more years until it’s done and providers start implementing.

My prediction is that passwords will be around for a long time, at least the next 10 years.

It can vary by implementation need. Can you send a time-limited secret as a login link to someone's email as a replacement to entering or managing passwords? Can you use PassKeys? Or a simple username and password? (Password storage and management is left as an exercise to the reader.)

Part of the question is - why present a login? Do you need an identity? Do you need to authorize an action? How long should it last?

Generally, today, PassKeys are the "simple" authentication mechanism, if you don't need a source of third-party identity or can validate an email address yourself. (Though once you implement email validation, it is arguable that email validation is a perfectly simple and valid form of authentication, it just takes a bit more effort on the part of the user to login, particularly if they can't easily access email on the device they are trying to login on, though even then you can offer a short code they could enter instead.)

Frankly, the conclusion to "how to login" that I draw today is that you will inevitably end up having to support multiple forms of login, including in apps, browsers and by email. It seems inevitable then that you will end up needing more than one approach as a convenience to the end user depending on the device they are trying to sign in to, and their context (how necessary is it that they must be signed in manually vs using a magic link or secret or QR code or just click a link in their email).

I should also note that I haven't discussed much about security standards here in detail. Probably because I'm trying to highlight that login is primarily a UX concern, and security is intertwined but can also be considered an implementation detail. The most secure system is probably hard to access, so UX can sometimes be a tradeoff between security and ease-of-access to a system. It's up to your implementation how secure you might need to be.

To some, you can use a web-based VPN or an authenticating proxy in front of your app, and just trust the header that comes along. Or you could put your app behind Tailscale or another VPN that requires authentication and never login a user. It's all up to what requirements the app has, and the context of the user/device accessing it.

It's probably going to be vendor-specific or you will implement your own auth. At ZITADEL we decided to offer all the standards like OIDC and SAML, and offer a session API for more flexible auth scenarios. You will also be able to mix.

> no currently known security problems

To be fair, that is the layman's definition of "secure"

But when you can use them, cookies are demonstrably better. XSS is the main argument against localstorage. Even this article[0], which pillories cookies, starts off with:

   ...if your website is vulnerable to XSS attacks, where a third party can run arbitrary scripts, your users’ tokens can be easily stolen [when stored in localstorage].

* APIs might require an authorization header in the browser fetch call.

* APIs might live on a different domain, rendering cookies useless.

CSRF is a danger, that's true. can be worked around. My understanding is that XSS has a wider scope and that many modern frameworks come with CSRF protection built in[1]. Whereas XSS is a risk any time you (or anyone in the future) includes any JS code on your website.

0: https://pilcrowonpaper.com/blog/local-storage-cookies/

1: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Re...

CSRF is not as big of an issue as it used to be, and when it is an issue it can be solved more easily and comprehensively than XSS:

1. The default value for SameSite attribute is now "Lax" in most browsers. This means that unless you explicitly set your authentication cookies to SameSite=None (and why would you?), you are generally not vulnerable to cookie-based CSRF (other forms of CSRF are still possible, but not relevant to the issue of storing tokens in local storage or cookies).

2. Most modern SSR and hybrid frameworks have built-in CSRF protection for forms and you have to explicitly disable that protection in order to be vulnerable to CSRF.

3. APIs which support cookie authentication for SPAs can be deployed on another domain and use CORS headers to prevent CSRF, even with SameSite=None cookies.

On the other hand, there are no mechanisms which offer comprehensive protection from XSS. It's enough for a single JavaScript dependency that you use to have a bug and it's game over.

For this reason, OAuth 2.0 for Browser-Based Applications (draft)[1] strongly recommends using a HttpOnly cookie to store the access token:

"This architecture (using a BFF with HttpOnly cookies) is strongly recommended for business applications, sensitive applications, and applications that handle personal data."

With regards to storing access tokens and refresh tokens on local storage without any protection it says:

"To summarize, the architecture of a browser-based OAuth client application is straightforward, but results in a significant increase in the attack surface of the application. The attacker is not only able to hijack the client, but also to extract a full-featured set of tokens from the browser-based application.This architecture is not recommended for business applications, sensitive applications, and applications that handle personal data."

And this is what it has to say about storing the refresh token in a cookie, while keeping the access token accessible to JavaScript:

"When considering a token-mediating backend architecture (= storing only access token in local storage), it is strongly recommended to evaluate if adopting a full BFF (storing all tokens in a cookie) as discussed in Section 6.1 is a viable alternative. Only when the use cases or system requirements would prevent the use of a proxying BFF should the token-mediating backend be considered over a full BFF."

In short, the official OAuth WG stance is very clear:

1. HttpOnly cookies ARE better in terms of security. 2. Storing Refresh Tokens in local storage is only recommended for low-security use cases (no personal data, no enterprise compliance requirements). 3. Storing short-lived Access Tokens in local storage should only be considered if there are technical complexities that prevent you from using only cookies.

[1] https://datatracker.ietf.org/doc/html/draft-ietf-oauth-brows...

enable same-site??

if you're doing things not from same-site, I'd posit you're doing something I want blocked anyways.

Maybe I’m not your target audience but Yikes! Your pricing was unexpectedly high.

Also it’s not clear what premium features were or why MFA is a premium feature but only available at top tiers.

You are describing enterprise, not normal b2b. Majority of businesses out there buying SaaS/PaaS products are not big enterprise with SSO needs nor compliance requirements. The SMB market is huge.

Enterprise types of users are their own beast.