Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Identity Core Api Laravel Package

liberusoftware/identity-core-api

A Laravel/PHP package providing the core API layer for identity services, with endpoints and supporting classes for managing identities and authentication records. Integrates with Liberu identity packages to give applications a consistent, reusable identity API surface.

View on GitHub
Deep Wiki
Context7

Product Decisions This Supports

  • Build vs. buy vs. borrow for the identity API surface. This package is a presentation adapter — the HTTP/API layer that sits over an identity domain core. That framing makes the decision concrete: it does not answer "what identity features do we ship," it answers "do we hand-write our auth endpoints and request/response contracts, or adopt a pre-shaped adapter?" For most teams the honest answer is borrow the shape, build the code.
  • API contract definition for the identity vertical. Because a presentation adapter encodes routes, payloads, status codes, and error formats, reviewing it is a cheap way to pressure-test your own identity API contract before you commit to it in a roadmap. Treat it as a design input, not a dependency.
  • Roadmap sequencing for auth-adjacent features. Registration, login, token issuance, password reset, profile read/update, and session handling are the usual contents of an adapter like this. Mapping its surface against your backlog tells you which identity stories are "solved boilerplate" and which are genuinely differentiating work worth scheduling.
  • Architecture standardization (ports-and-adapters). Adopting the adapter pattern explicitly lets you swap REST for GraphQL or gRPC later without touching domain logic. If your roadmap includes multiple client surfaces (web, mobile, partner API), this is a legitimate structural argument independent of this specific package.
  • Shared identity across a multi-product portfolio. If the org runs several Laravel products, a single identity contract reduces duplicated auth work and inconsistent security posture — a real cost saver that a PM can put a number against.
  • Vendor and OSS dependency gating. 0 stars, 0 dependents, and a NOASSERTION license make this a useful forcing function: it lets you define and socialize a dependency acceptance bar (license clarity, maintainer count, release cadence, CVE responsiveness) before the first package slips through.

Caveat to carry into any decision: the published metadata is itself a signal. A NOASSERTION license means the license could not be identified from the repository — that is a legal blocker, not a formality. The "last release" date of 2026-10-26 is in the future relative to normal consumption, which suggests unreliable or synthetic registry metadata; verify against the actual repository before treating any number here as fact.

When to Consider This Package

Consider it when:

  • You are already inside the Liberu modular Laravel stack and the identity domain module is present — this adapter is only meaningful as a companion to that core, not standalone.
  • You want a thin, low-LOC reference for how to shape identity endpoints, and your team is comfortable reading code as documentation.
  • You are running a short, timeboxed spike and can pin to a specific commit or tag with the code vendored into your own tree.
  • Your compliance posture tolerates a pre-1.0, single-maintainer dependency for internal or non-customer-facing surfaces only.
  • You need the adapter pattern itself — hex/ports-and-adapters for identity — and want a worked example to point engineers at.

Look elsewhere when:

  • You need production authentication. Laravel Fortify/Jetstream/Breeze for scaffolding, Sanctum for token auth, Passport for OAuth2, or off-the-shelf IdPs (Auth0, Cognito, Keycloak, Ory) if identity is not your differentiator. Any of these is a lower-risk default at this package's maturity.
  • License clarity is a hard gate. NOASSERTION with no dependents and no visible commercial backing means legal cannot clear it, and you cannot ship it in a distributed or enterprise product without written clarification from the maintainer.
  • You need support guarantees. Zero stars and zero dependents means bus factor of one, no community answers, no third-party tutorials, and no evidence anyone has run this in anger.
  • You need semantic versioning, deprecation policy, or a security disclosure process. None are evidenced here.
  • You are outside the Liberu ecosystem. The cost of adopting the surrounding module conventions will exceed the value of a presentation layer you could write in a sprint.
  • Your team has no bandwidth to own a fork. Realistically, adopting this means forking it. If nobody owns that fork, don't adopt it.

Practical recommendation: timebox a 1–2 day evaluation spike. Read the routes and contracts, extract the API shape into your own spec, then decide. Do not add it to composer.json for a production service until the license is resolved and a named engineer owns the dependency.

How to Pitch It (Stakeholders)

To executives: This is a small, unproven open-source adapter for the API layer of an identity system — the part that defines how clients talk to login and account services. It is not an identity product and it is not a security control. The value on offer is time saved on boilerplate and a cleaner architectural seam, not a feature. The risk is a near-total absence of adoption evidence (zero stars, zero dependents, one maintainer) and an unresolved license. Recommendation: fund a short evaluation to harvest the API design, and hold off on any production dependency until license and ownership are settled. Cost of the spike is measured in days; cost of an unresolved license in a shipped product is measured in legal review and rework.

To engineering: Treat this as a reference implementation of a presentation adapter over an identity domain module, not a library. It is thin, it is pre-1.0, and nobody else is using it, so expect to fork and own it. The upside is that the adapter boundary is the right boundary — it keeps transport concerns out of domain logic and makes a future GraphQL or gRPC surface a swap rather than a rewrite. Action: 1–2 day spike, extract the route/payload contract, assess whether the surrounding module conventions are worth the coupling, and report back with a build-vs-borrow estimate. If we adopt, we pin a commit, vendor it, and name an owner.

Bottom line: high architectural relevance, very low maturity. Use it to inform decisions, not to make them for you.

Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
uni-method/symfony-lib
tacticmedia/scim-server-bundle
neika-ai/symfony-bundle
mattleads/agent-publishing-bundle
glavweb/framework-bundle
glavweb/extra-bundle
glavweb/api-bundle
glavweb/admin-bundle
adachsoft/api-version-bundle
elsayed85/laravel-api-exceptions
ouhssini/laravel-demo-mode
daworks/ncloud-outbound-mailer-driver
gp247/cms
ignibyte/aic-gates
nexa-merchant/blog
novasa/laravel-language-center
opencage/geocode
adolfoholzer/parameters
livenetworks/ln-starter
shitoudev/permissionmanager