[chowells]

> While OpenAuth tries to be mostly stateless, it does need to store a minimal amount of data (refresh tokens, password hashes, etc). However this has been reduced to a simple KV store with various implementations for zero overhead systems like Cloudflare KV and DynamoDB. You should never need to directly access any data that is stored in there.

Written like someone who's never actually maintained an identify provider used in B2B contract work. You will inevitably come into contact with people who cannot make things work on their side and are doing things so unexpectedly that logging is insufficient to track down the error. Sooner or later you will need to look at the data actually in storage to figure out what your customers who are threatening to cancel their contract are doing wrong.

I've been there. Many times.

[Alupis]

KV Stores aren't magical... and you do need to store this data somewhere.

So what's different between this (or any of these new-aged Auth services) and something else more traditional? If anything, these new-age services make it easier to access your data if you need to, since you often control the backing database unlike auth0, etc.

Both DynamoDB and Cloudflare KV are queriable.

I guess I don't understand the negativity in your comment. If anything, your complaint sounds like an issue you and your team cooked up on your own.

[skywhopper]

I don’t think it’s the architecture or technology the commenter is reacting to, it’s this line: “You should never need to directly access any data that is stored in there.”

Statements like that are a huge red flag that the designers of the product are not particularly experienced with operating this type of system at meaningful scale.

[Alupis]

Eh, the technology stack they discuss is directly accessible, though.

I read this as an advertisement, meaning if everything it working well you don't need to manage the database. Which is probably how it works 99% of the time in fairness.

[inopinatus]

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.

[IgorPartola]

To me this statement read very differently. I read it as saying that the amount of state is small and portable enough that I wouldn’t have to worry about scalability issues or be married to a particular database product. I think the original complaint about it is overly critical and nit picking.

[thdxr]

yes this was the intent

[pixl97]

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

[afiori]

Sure but you are allowed to put the 99% front and center in marketing.

A good chunk of the other 1% are square-peg-in-round-home situations.

It is good to support all the various edge cases but it is also on 6 to focus on the happy path

[victor106]

> since you often control the backing database unlike auth0, etc.

Auth0 has an option where you can use your own database for identities

[Alupis]

Starting at $240 a month...

[thdxr]

all of the data in there will be exposed via an API and also directly queryable since it's in your infra

but the idea here is openauth does not handle things like user storage - it just gives you callbacks to store the data in whatever database you're using

precisely because of what you're talking about - eventually you need access to it