Auth Laravel Laravel Package

Product Decisions This Supports

• Security and compliance roadmap: v0.27.0 adds opt-in durable OAuth credential revocation for Laravel/Passport-style flows, closing the gap where revoked authorization codes, access tokens, or refresh tokens could remain valid until cache TTL expiry or token decryption. This supports enterprise security, audit, incident response, and customer-trust commitments.
• Feature scoping: The release enables owner-level and connection-level revocation with database-backed connection lineages and revocation sequences. PMs can scope features around user offboarding, client compromise, refresh-token rotation, and audit-driven revocation without building lineage tracking and transactional barriers in-house.
• Build vs. buy/adopt: If the product runs Laravel Passport and needs revocation guarantees that survive rotation and purges, adopting this package is likely cheaper and lower-risk than designing, validating, and maintaining the migration, lineage, and fail-closed issuance logic internally.
• Rollout strategy: The feature is opt-in and default-off. This makes it suitable for staged adoption behind a config flag, but PMs must plan a migration, enablement, guarded revocation operations, custom issuance wrapping via duringIssue(), and coordination with issuance pauses during rollout.
• Risk trade-off: The package deliberately fails closed for later unregistered writes and unknown owner/client grants, which is the right product posture for security-sensitive environments but requires planning for legacy grants and migration sequencing.

When to Consider This Package

• Consider it when the product uses Laravel/Passport OAuth and must ensure revoked grants cannot outwait revocation through caches, TTLs, token decryption, or rotation.
• Strong fit when the product needs owner-level revocation, client-level revocation, same-client sibling connection preservation, audit selection, refresh-token rotation tracking, or credential lineage visibility.
• Consider it for regulated, enterprise, or high-trust environments where revocation must be durable across database persistence, Passport purge, and migration rollback.
• Adopt only if the team can perform the required migration, enable oauth_server.revocation.enabled, use the guarded revocation operations, wrap custom issuance decisions in duringIssue(), and coordinate rollout with issuance paused.
• Look elsewhere or defer if the product does not use Passport, uses a third-party identity provider for revocation, has only simple non-rotating tokens, cannot accept schema/migration changes, cannot pause issuance during rollout, or needs a fully turnkey revocation system with no application integration work.
• Also look elsewhere if the team cannot support a fail-closed model for unregistered grants and unknown owner/client connections, or if legacy grant registration during migration is operationally impractical.

How to Pitch It (Stakeholders)

For executives: v0.27.0 is a security-focused, opt-in release that makes OAuth credential revocation durable. It reduces the risk that revoked access survives in caches or token state, supports audit and incident-response requirements, and is not enabled by default. The main cost is a coordinated migration and rollout, not a forced platform change.

For engineering: The release introduces database-backed connection lineages, owner/client revocation sequences, and transactional guards around authorization-code, access-token, and refresh-token persistence. Adoption requires migrating Passport’s connection, enabling the revocation config, using revokingOwner() / revokingConnection() for guarded revocation, wrapping custom issuance decisions in duringIssue(), and coordinating rollout with issuance paused. Existing owner revocation methods adopt the new barrier automatically, legacy grants are registered at sequence zero by the migration, and unknown or later unregistered grants fail closed.