I wrote an identity/auth service that had the backend like that intentionally. I wanted to be able to adapt it to pretty much any backend that was desired. Each identity had 4 entries with predictable keys, and the data was json that was optionally encrypted through the app, if using a dbms that didn't provide encryption at rest.

The data access interface was simple enough, that it allowed interface layering allowing for different backends, encryption, etc. to be very flexible.

I had adapters for SQLite (default), MS-SQL, PostgreSQL, Redis, Cassandra and AWS DynamoDB. It was deployed for apps that went from embedded, to integrated with our applications, and external applications on internal and external infrastructures.

The only disappointing thing is that I wasn't allowed to open-source/release the application. The concern is it would be a security risk if anyone knew how the application worked. I still disagree with this decision. It was a bit simpler, and more flexible than "Identity Server" in use, but it served the needs of a lot of applications where an existing identity provider (IS, Octa, AD Auth, etc) wasn't already in place. Most of the apps I worked on at that company had used JWT allowing for somewhat flexible configurations of RSA signed providers... integration usually consisted of a bridge service for authentication going from the client's provider to an app targeted JWT. This kept integrations separate.

Sorry for veering off a bit.

> The concern is it would be a security risk if anyone knew how the application worked

Uh, that's the classic security through obscurity (STO) defense on the face of it but it sounds like a cop-out to not open source it. If one desires not to open something that's fine, but if they misrepresented the reason for doing so would be bullshit.