Paseto Laravel Package

Product Decisions This Supports

• Migration from JWT/JOSE: Replace insecure or outdated JWT implementations (e.g., libraries with known vulnerabilities like firebase/php-jwt or lucas-vasques/jwt) with a modern, cryptographically sound alternative. PASETO eliminates design flaws in JWT (e.g., lack of versioning, ambiguous key usage, and weak security assumptions).
• Zero-Trust Architecture: Enable public tokens for distributed systems where token issuers and consumers are distinct (e.g., microservices, third-party integrations, or API gateways). Avoids the need for shared secrets in cross-service communication.
• Key Rotation & Compliance: Implement key rings for seamless key rotation with overlap periods, critical for regulatory compliance (e.g., GDPR, HIPAA) or high-security environments (e.g., financial systems).
• Confused Deputy Protection: Use implicit assertions (v3/v4) to prevent token misuse across multi-tenant systems (e.g., SaaS platforms where tokens must be scoped to specific customers without exposing customer IDs).
• Build vs. Buy: Buy this package to avoid reinventing cryptographic token standards. The library handles edge cases (e.g., protocol versioning, footer validation) and integrates with PHP’s Sodium/GMP/OpenSSL extensions.
• Use Cases:
  • Session Management: Secure, tamper-proof session tokens with built-in expiration (setExpiration()).
  • API Authentication: Replace OAuth2 access tokens with PASETO for reduced attack surface (no JWT parsing libraries).
  • Data Integrity: Embed metadata in token footers (e.g., audit logs, non-sensitive claims) without encrypting the entire payload.
  • Multi-Cloud/Hybrid Systems: Use public tokens for cross-cloud communication where services don’t share secrets.

When to Consider This Package

• Adopt PASETO if:

  • You’re using JWT/JOSE and want to eliminate cryptographic risks (e.g., algorithm confusion, weak signatures).
  • Your system requires forward secrecy (e.g., keys can be rotated without breaking existing tokens).
  • You need fine-grained token validation (e.g., implicit assertions, footer rules, or key rings).
  • Your stack is PHP 8.1+ (or PHP 7.1+ for legacy support) with access to OpenSSL/GMP/Sodium.
  • You’re building a distributed system where token issuers and consumers are separate entities.

• Look elsewhere if:

  • You need broad ecosystem support (PASETO is niche; JWT has libraries for every language).
  • Your team lacks cryptographic expertise (PASETO requires careful key management).
  • You’re constrained by legacy systems that mandate JWT (e.g., OAuth2 providers).
  • You prioritize token size over security (PASETO headers are larger than JWT’s).
  • Your use case is simple (e.g., internal tools with no token validation needs).

How to Pitch It (Stakeholders)

For Executives:

"PASETO is a drop-in replacement for JWT that fixes critical security flaws while adding modern features like key rotation, multi-tenant isolation, and confused deputy protection. By adopting this, we eliminate risks from vulnerable JWT libraries (e.g., CVE-2022-23529 in firebase/php-jwt) and future-proof our authentication for distributed systems. The upfront cost is minimal—just a PHP package upgrade—with long-term benefits in security audits and compliance. For example, [Company X] reduced token-related vulnerabilities by 90% after switching from JWT to PASETO."

For Engineering:

*"This library gives us:

1. Security: PASETO’s design avoids JWT’s pitfalls (e.g., no ambiguous key usage, explicit versioning).
2. Flexibility:
   • Local tokens for internal services (encrypted, shared-key).
   • Public tokens for cross-service auth (unencrypted, asymmetric).
   • Key rings for zero-downtime key rotation.
3. Validation: Built-in rules for expiration, issuers, and footer data (e.g., block tokens with malformed JSON footers).
4. Performance: Uses PHP’s Sodium/GMP extensions (or sodium_compat as fallback). Migration path: Start with v4.local for internal auth, then expand to v4.public for APIs. The library’s type safety prevents misusing keys (e.g., TypeError if you try to sign with a public key)."*

For Security/Compliance Teams:

*"PASETO addresses:

• Algorithm Confusion: Explicit protocol versions (e.g., v4.local) prevent downgrade attacks.
• Key Management: Key rings enable granular access control and audit trails for rotation.
• Data Leakage: Implicit assertions let us validate claims (e.g., customer-id) without exposing them in tokens.
• Regulatory Alignment: Supports cryptographic agility (e.g., switch to post-quantum algorithms when available). Example: For GDPR, use footer rules to limit token claims to authorized scopes without decrypting payloads."*