Octawire Auth Service Php Client Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy on identity: This package is an opinionated client for a single Auth Service (Octowire). If your roadmap includes SSO, token issuance, JWT validation, and claims handling, adopting this pushes you toward a buy/integrate stance rather than building auth in-house. That is usually the right call — auth is high-risk, low-differentiation work — but it also means a hard dependency on one vendor's protocol.
• Protocol standardization milestone: v0.9.4 aligns with "Auth Service Protocol v1.0" and the JATP_METHODS_1.0.json spec. For a PM, this is the signal that the wire contract is stabilizing — a precondition before you commit to it in a customer-facing or compliance-sensitive roadmap (audit logging, token lifecycle, multi-tenant projectId scoping).
• Multi-tenancy / project scoping: First-class projectId support (and the fix ensuring it's passed to ValidateTokenRequest) means you can model per-project or per-tenant token validation. This directly enables B2B/multi-workspace features on the roadmap.
• Camel case = cross-platform interoperability: Supporting camelCase v1.0 fields with snake_case fallback opens the door to non-PHP services (Node, Go, mobile) sharing the same contract. Useful if your architecture decision is "polyglot services, one auth protocol."
• Migration cost planning: The release includes a README migration guide, INSTALLATION.md changes, and integration test examples — PM-relevant because it quantifies upgrade effort for engineering planning and reduces risk of a "surprise" sprint.
• Feature gate for health/status reporting: HealthCheckResponse.healthy (bool) → status (string) is a meaningful behavioral change — if you surface auth service health on an internal dashboard or in SLOs, this affects what you can display.

When to Consider This Package

Consider it when:

• You are building a Laravel/PHP application that needs to authenticate against an Octowire Auth Service (or a service implementing Auth Service Protocol v1.0 / JATP 1.0).
• Your stack is PHP 8.1+ and Symfony 6.4+/7.0+ — the package's floor matches modern Laravel.
• You need JWT issuance, token validation, custom claims, and per-project (projectId) scoping without rolling your own crypto/claims logic.
• You value a documented migration path and real integration tests against the live Auth Service — evidence of maturity for a pre-1.0 package.
• You need backward compatibility during a transition (snake_case still works), so you can upgrade the client before you finish migrating downstream consumers.

Look elsewhere when:

• You are not on Octowire / Auth Service Protocol — this is a vendor-specific client, not a generic OIDC/SAML library. For standard SSO, evaluate Laravel Socialite, Passport, Sanctum, or an OIDC provider instead.
• You require a stable 1.0 API guarantee. This is 0.9.4; a pre-1.0 package can still change field names (v0.9.4 itself changed healthy → status). If your release cadence can't absorb minor-version breaking changes, wait for 1.0 or pin aggressively.
• You need SAML, SCIM, social login, or MFA orchestration — not in scope of this release.
• Your runtime is PHP < 8.1 or Symfony < 6.4.

How to Pitch It (Stakeholders)

For executives — one paragraph:

We are evaluating an official client for our authentication service. The new release (v0.9.4) brings it in line with the finalized Auth Service Protocol v1.0, fixes a token-validation bug that would have blocked production use, and adds real integration tests against the live service. In plain terms: authentication is now a solved, vendored capability we can adopt rather than build — reducing security risk and engineering time, while keeping our migration path documented and reversible. The main caveat is that the library is still pre-1.0, so we should pin the version and plan for occasional minor upgrades.

For engineering leads:

v0.9.4 supports Protocol v1.0 (camelCase) with snake_case fallback, so you can upgrade the client now and migrate consumers later. Watch three things: (1) HealthCheckResponse.healthy is now status: string — update any health dashboards; (2) the projectId fix means token validation now requires it explicitly — verify your config; (3) dependencies are Symfony 6.4+/7.0+ and PHP 8.1+. The README migration guide, INSTALLATION.md, and examples/integration-tests/ cover the upgrade, and 88 unit tests plus verified live integration tests back it. Pin to ^0.9.4 and track the 1.0 milestone.

Recommendation: Adopt behind a version pin for internal/back-office and B2B multi-tenant auth flows where the Octowire Auth Service is already the target. Do not expose to a customer-facing SLA commitment until a 1.0 release confirms API stability.