Client Laravel Package

Product Decisions This Supports

• Build vs. buy on identity. The single biggest decision this unlocks: do we hand-roll authentication/authorization in Laravel (Sanctum/Passport + custom tables) or delegate to Ory (Kratos for identities, Hydra for OAuth2/OIDC, Keto for permissions)? This package is the cost-of-integration lever in that equation — it converts "we'd need to build a service" into "we call typed API methods." If the integration cost is a two-day spike, buying becomes the obvious answer; if it's a quarter, it doesn't.
• Roadmap scoping for B2B/enterprise features. SSO/SAML, MFA, passkeys, session management, org multi-tenancy, and audit trails are the requests that stall a mid-market roadmap. Deciding to let Ory own them means those items move from "build" to "configure," which directly changes what we can promise in the next two quarters.
• Deferring auth from the product roadmap entirely. Auth is undifferentiated for most products. Adopting this keeps engineering on the core domain and turns identity into an operational line item instead of a feature backlog.
• Back-office and operations tooling. Admin provisioning, bulk user migration, forced session revocation, OAuth2 client registration, and test-data seeding in CI — all become API calls from an internal Laravel admin panel rather than manual dashboard work.
• Authorization architecture. If we're evaluating a move from role columns to relationship-based access control, Keto checks wired into Laravel Gates/Policies is a concrete, assessable path — small blast radius, testable in one sprint.
• Compliance and incident response scope. Centralized identity means one deprovisioning path, one audit source, one place to answer "who had access on date X." That's a measurable reduction in SOC 2 / ISO 27001 evidence-gathering effort.
• Vendor optionality. Because the underlying service is standards-based (OIDC/OAuth2) and this client is generated from an open spec, committing here doesn't lock us into a proprietary user store. That makes the decision reversible — a rare property in identity vendors, and worth weighting heavily.

When to Consider This Package

Consider it when:

• You are already on, or actively evaluating, Ory (Ory Network or self-hosted Kratos/Hydra/Keto). Outside that context it is dead weight.
• You need programmatic identity operations from PHP/Laravel — admin panels, migrations, provisioning scripts, CI fixtures, or permission checks inside application code.
• Your team is comfortable owning a thin integration layer. There is no Laravel service provider; you wire up HTTP client, config, and error handling yourself.
• You'll use a focused set of endpoints (5–15). A generated client pays off as a typed convenience wrapper, not as a full abstraction.
• You'd rather regenerate than fork. The code is machine-produced from the Ory OpenAPI spec, so an upgrade path exists even if the PHP repo itself goes quiet.

Look elsewhere when:

• You only need login and sessions for a monolith — Laravel Sanctum/Passport/Breeze is the correct answer and always will be.
• You want a first-party SDK with documentation, support contracts, and a large PHP user base — Auth0, WorkOS, Clerk, FusionAuth, or Cognito via the AWS SDK.
• You need vendor support as a contractual obligation. Ory's commercial support covers the platform, not this repository; if the SDK is on your critical path, that asymmetry matters.
• You need only OIDC login, with no management APIs. A generic OIDC client or Socialite driver is lighter — this package's value is in the admin/management surface, not the redirect flow.
• Low adoption is a blocker for your governance process. Seven stars and zero dependents is a real signal about the PHP ecosystem's engagement with Ory, even if the code itself is low-risk. Mitigate by vendoring or regenerating from spec, and by wrapping it in an internal adapter — but if your review board won't accept that mitigation, don't fight it.

How to Pitch It (Stakeholders)

To executives: This is a free (Apache-2.0), small adapter that lets us buy identity instead of building it. It moves SSO, MFA, and user administration off our roadmap and onto a vendor's, which is where commodity capabilities belong. There is no license cost, no proprietary user store, and — because the service speaks standard OIDC/OAuth2 and the client is generated from an open specification — a credible exit ramp if the relationship sours. The ask is a timeboxed spike, plus budget for platform seats if we choose the hosted option.

To engineering: Typed request/response models over Guzzle, generated from Ory's OpenAPI spec, so upgrades are regeneration rather than migration. We own the integration layer: config, DI binding, retry/timeout policy, and error mapping. Recommended pattern is an anti-corruption layer of our own interfaces wrapping the client, so the blast radius of swapping it out later is a single namespace. Pin the client version against the Ory API version we target, and add a contract test that hits a sandbox tenant.

On the risk: The honest framing is that the PHP client's low adoption is a maintenance signal, not a security signal — the dependency that actually matters is Ory as a service, and this repo is replaceable by regenerating from spec. Recommendation: run a one-to-two day spike against a sandbox tenant covering provisioning, session revocation, and one permission check, then decide with evidence rather than stars.