Sessions Devices Api Laravel Package

Product Decisions This Supports

• Shipping a "Security Center / Active Sessions & Devices" surface. This adapter is the API presentation layer for session and device data — the thing that turns domain records into a consumable endpoint for a settings page or admin console. That directly enables: list logged-in devices, last-seen/IP/geo metadata, per-session revoke, and "sign out everywhere."
• Account-takeover and fraud reduction roadmap. New-device login notifications, suspicious session flags, and forced re-authentication are the highest-ROI security features per engineering dollar in B2B SaaS. A clean sessions/devices API is the prerequisite for all of them.
• Plan-tier monetization and policy enforcement. Concurrent session limits, device-count caps, and "trusted device" allowances are packaging levers (e.g., 1 device on Starter, unlimited on Enterprise). This package gives you the read model to enforce and display them.
• Build vs. buy signal: build the contract, buy/borrow the plumbing. Because this is explicitly a presentation adapter, it isolates the API contract from the domain. That means the decision to adopt or replace it is cheap and reversible — a good property when you're unsure about the vendor.
• Compliance and security-questionnaire throughput. SOC 2 / ISO 27001 access-control evidence and GDPR data-subject requests (enumerate and purge device records) are recurring sales blockers. A structured sessions/devices API shortens those answers from "custom work" to "already supported."
• Support and CX tooling. CS can inspect a customer's active devices to resolve "I keep getting logged out" tickets instead of escalating to engineering.
• Reusable adapter pattern for the public/partner API. If this pattern is already established in your codebase, the same structure carries over to other resources — a modest architectural dividend.

When to Consider This Package

Consider it when:

• You are already inside the Liberu module ecosystem (module-*, presentation-adapter conventions). In that case integration cost approaches zero and the conventions match.
• You need a thin HTTP presentation layer over existing session/device domain models — not a new authentication system, not a new identity provider.
• You are willing to pin an exact version, vendor the source, and treat it as internal code you own.

Look elsewhere when:

• You need maintained, battle-tested session management. Laravel's native session/database driver plus Sanctum or Passport, or Jetstream/Fortify's first-party session management, cover the 80% case with actual community support.
• You need device trust, MFA, or anomaly detection as a product. That is a buy decision (Auth0, WorkOS, Clerk, FusionAuth, Stytch) — not something a zero-dependency adapter provides.
• License clarity is a gate. NOASSERTION means the terms are unverified. Legal review is mandatory before it enters your supply chain; if your policy requires OSI-approved licenses, stop here.
• You need an SLA, security disclosure process, or responsive maintainer. Zero stars, zero dependents, and a single-publisher footprint means no community safety net and no escalation path.
• Provenance can't be confirmed. The listed last release date (2026-10-26) is not credible as a normal artifact timestamp; verify the actual package contents and publisher before pulling it in.
• You are not on PHP/Laravel, or you are standardizing on a managed identity provider.

Adoption posture: spike/evaluate, not strategic dependency. Time-box to 1–2 days, wrap it behind your own interface, and keep a first-party Laravel fallback.

How to Pitch It (Stakeholders)

To executives: This is a small adapter that lets us ship a "your devices and sessions" security feature quickly — the ability for customers to see where they're logged in, kill stale sessions, and get notified about new devices. For B2B buyers, that's now table stakes in security questionnaires, and it measurably reduces account-takeover incidents and lockout tickets. Cost and risk are both low: it's a presentation layer, not core infrastructure, we pin and own the code, and we can replace it without customer-visible change. The caveat is equally simple — it's an unproven, single-maintainer component with unclear licensing, so we should not build a multi-year dependency on it or expect vendor support.

To engineering: It's a hexagonal presentation adapter — HTTP contract over sessions/devices domain models, no domain logic. If we're already in the Liberu module conventions, integration is a wiring exercise; if we're not, a comparable adapter on Sanctum is roughly a one-to-two-day build and gives us code we own outright. Either way, put it behind an internal interface so we can swap the implementation.

Recommendation: Fund a short spike with a hard exit criterion — if licensing isn't cleared or provenance can't be verified, default to the first-party Laravel path. Success metrics to instrument: reduction in "locked out / can't log in" tickets, share of users who review active sessions, median time-to-revoke a compromised session, and the number of security questionnaires we can answer without custom engineering.