One Identity Layer Instead of Five
Every product needs login, organizations, roles, SSO and an audit trail. I had built that more than once, a little differently each time. Identity is the last thing you want five diverging copies of, so it became laravel-id: a self-hostable, contract-driven identity platform for Laravel.
In the last post I wrote about pulling code that was already in production out of individual projects and into single open source packages. Identity is the same story, told about the one piece you least want to keep rewriting.
Every product I have built needs the same spine: a login, organizations, roles, sometimes enterprise SSO, an audit trail a compliance review will ask to see. I built that spine more than once, a little differently each time, because each product had its own deadline and its own shortcuts. Five logins is bad. Five subtly different authorization models is worse. It is the one area where drift between copies is not a maintenance annoyance, it is a security risk.
The framework
So the spine became a framework library. It is UI-free and domain-free: every capability sits behind a contract you bind, mock, extend or replace. It is split into kernels, Tenancy, Crypto, Audit, Events and Authorization, and domain modules, Organization, Identity, AccessControl, Directory for SCIM, Federation for SSO, Webhooks and AuditQuery. You resolve a contract from the container and get a working implementation, and you can swap any of it without touching your call sites.
It is deny-by-default throughout, and it implements the standards an identity platform is expected to rather than inventing its own: OAuth and OIDC, SCIM, SAML, plus FAPI and MCP. The docs map controls to SOC 2, ISO 27001, NIS2, GDPR, HIPAA and PCI-DSS, and ship a threat model next to the security guidance, because those are the questions that actually get asked when identity leaves a side project and enters a real one.
The app is public, not released
There is also an app: Cbox ID, the hosted and self-hostable admin console built on top of the framework. I have put its repository out in the open, but I want to be clear about where it stands.
Cbox ID the app is not tagged yet
The application repository is public, but it has no release tag and is not a stable release. It is out in the open so the work can be followed, not because it is ready to run in production. The framework, laravel-id, is what you can build against today. When the app reaches a stable tag, I will say so.
Why the second pass matters most here
The same caveat from the extraction post applies, and it applies hardest to identity. This is reshaped code, not the verbatim copies that ran in production. It moved behind contracts, it was tightened, and in places it was extended. That reshaping is the point, but it means the early releases can carry bugs or gaps the originals did not. For a security-sensitive layer that is worth saying plainly rather than burying.
So the invitation is the same, and I mean it more here than anywhere: if you build against this and something looks wrong, off, or missing, open an issue or a PR. Identity is the one place where an extra pair of eyes on the first release is worth the most.
Try it
composer require cboxdk/laravel-idThe documentation covers installation, the module layout, the standards it conforms to and the compliance mapping. More packages are on the way as the rest of the old logic gets its turn through the same second pass.
