Antenna Bundle Laravel Package

Product Decisions This Supports

• Session/token lifetime policy. Release 1.1.0 adds a time_to_live option to UsernamePasswordAuthenticator, so credential lifetime becomes a configuration decision rather than a hard-coded behavior. PMs can set product-level expiry per environment, guard, or customer tier (short for admin/high-risk surfaces, longer for low-risk consumer flows) without middleware forks or custom auth code.
• Security & compliance posture. Directly supports "absolute/idle timeout" controls that show up in SOC 2, ISO 27001, and PCI reviews. Having this as a first-class option shortens security questionnaires and avoids a bespoke implementation each time a customer asks for a session limit.
• Build vs. buy. Credential verification and TTL plumbing are undifferentiated but security-sensitive. Adopting the package keeps engineering effort on authorization rules, onboarding UX, and audit logging instead of rebuilding auth primitives.
• Roadmap enabler. Per-authenticator TTL is a prerequisite for tiered-trust sessions: step-up auth, "remember this device," partner/B2B contractual session caps, and re-authentication cadence for sensitive actions. It is a foundation block, not the whole feature.
• Use cases to prioritize. Internal admin consoles, B2B/partner portals with contractual timeout terms, and regulated workflows (payments, health, HR data) where periodic re-auth is mandated.

When to Consider This Package

Adopt when:

• You run a Laravel application that needs first-party username/password login with a configurable credential lifetime.
• You want TTL expressed in config (per guard, per environment) rather than baked into application code.
• Your team already works with Laravel's auth contracts and guards; the package should slot in, not replace the auth stack.
• You prefer a small, focused dependency over standing up a full identity platform for a single auth flow.
• A short, auditable answer to "how long does a login last, and who decides?" is valuable to your security reviewers.

Look elsewhere when:

• You need MFA, OIDC/SAML federation, passwordless, or step-up authentication as first-class features — this is a credential authenticator, not an IdP.
• You need per-user, runtime-evaluated TTL (risk scoring, device trust) with an audit trail; you would wrap this package with a policy layer.
• Requirements include refresh-token rotation, revocation lists, or a user-facing "active sessions / revoke device" screen.
• Auth is on your critical path and the package carries single-maintainer or low-activity risk — in that case, fund an internal implementation or buy a dedicated identity provider.
• You need documented SLAs or vendor support contracts.

Adoption caveats to verify before committing: the behavior when time_to_live is not set (confirm it does not silently produce non-expiring credentials), whether TTL applies to issued tokens, sessions, or both, and how expiry interacts with refresh and logout.

How to Pitch It (Stakeholders)

For executives: A single configuration change now governs how long a login stays valid. That lets us tighten security for high-risk users or extend convenience for low-risk segments on a per-customer basis, without an engineering cycle each time. It also closes a common security-review finding around session timeout controls, which shortens enterprise and compliance sales cycles.

For engineering: 1.1.0 is additive and non-breaking — a time_to_live option on UsernamePasswordAuthenticator. Integration cost is low: it is configuration surface, not new infrastructure. Recommended actions are to pin the version, set explicit TTL values per guard rather than relying on defaults, add a test asserting expiry behavior, and document the chosen values so security and support teams can answer customer questions consistently.

Risk framing: Authentication is critical-path, so treat this as a dependency with an exit plan. Confirm the default when the option is omitted, confirm the package's maintenance cadence, and wrap the authenticator behind our own interface so a future swap does not touch product code.