[hc-taway]

> ORY Kratos, as an example, will happily create different conceptual types of users and you can store arbitrary data in those user documents, but it is modified through an API and exposes to you stable IDs against which you can code the rest of your application.

The stable-ID solution was how I handled this when I wrote one of these as an internal tool (guess you'd call it a "microservice") for a startup I worked for back in like 2010. In hindsight I guess I should have pushed to pivot to selling that as our product since we ended up selling the company for barely-pay-back-the-investors money, but who knew? Hahaha.

Also identified permissionable-objects as UUIDs, which let me handle authorization in addition to authentication. Creating a new "permission" object meant asking for one from the service, then you'd receive a UUID, associate that with whatever thing you were applying the permissions to on your end, and tell the service to assign the desired permissions. Then you could just query the permissions for that UUID (which could, potentially, represent a bundle of items, a single item, or permissions to an entire service—how to interpret it was left up to the consuming service) and of course cache them as much as you felt was proper. IIRC there as also a concept of owning-objects so you could let permissions be inherited, then override on a case-by-case basis, plus it'd let you ask which objects belonged to a given collection. IIRC I used that to represent organizations, too, since they were basically the same thing as a permissionable-object container themselves needing to be permissionable.

Not a perfectly-flexible system (billions of items that all need distinct permissions might have eventually forced sharding or something, but luckily we didn't have to worry about that) but it was rock solid for our purposes and made spinning up new services or products sharing login with our main product super-easy.