Workos Php Laravel Laravel Package

Product Decisions This Supports

• Build vs. buy on enterprise identity. The real decision this package rides on is whether to buy WorkOS rather than build SAML/OIDC, SCIM provisioning, and directory sync in-house. SAML/SCIM is months of engineering plus permanent maintenance across every IdP your customers use; WorkOS turns it into configuration. This package is only the Laravel glue — treat the buy decision as the WorkOS decision, and this as the implementation detail.
• Unblocking enterprise/upmarket revenue. SSO/SAML and Directory Sync are recurring checklist items in enterprise security reviews. "We support Okta/Entra/Google SSO and SCIM provisioning" is frequently the difference between advancing in procurement and stalling at the security questionnaire. That's a roadmap slot justified by pipeline, not by usage.
• Self-serve IT administration (Support cost reduction). The Admin Portal lets a customer's IT admin wire up their own SSO connection and directory without a ticket to your team. This is a support-load and onboarding-velocity decision as much as a feature — it removes your engineers from the IdP setup loop.
• Compliance and audit posture. Audit Logs plus centralized user management feed SOC 2 / ISO 27001 evidence, offboarding workflows (instant revocation on SCIM de-provision), and role-based access via the authorization surface. These are requirements decisions with deadlines, not nice-to-haves.
• Onboarding and auth UX bets. Magic Link and User Management open passwordless and managed-auth paths — useful if you're deciding whether to keep owning credential storage or delegate it.
• Feature scoping for the next 1–2 quarters. Concretely: enterprise tier gating, SCIM for large accounts, RBAC for plan/role tiers, Admin Portal for IT self-serve. Each is independently shippable and independently sellable.

When to Consider This Package

Adopt it when all of the following hold:

• The stack is Laravel 12+. Version 8.0.0 dropped Laravel 11 support; on L11 you're pinned to an older major and effectively frozen out of the current line.
• You've already decided (or are seriously evaluating) to buy WorkOS. This package has no value without a WorkOS account — it's an adapter, not a product.
• You want container-native ergonomics: it binds \WorkOS\WorkOS as a singleton, so you get facade, workos() helper, and constructor injection for free, plus config publishing driven by WORKOS_API_KEY / WORKOS_CLIENT_ID. That's a day of setup work you don't write or maintain.
• You're comfortable with frequent major-version upgrades. The changelog shows v5.1 → v6.0 (full rewrite; WorkOSService removed; accessors renamed: mfa()→multiFactorAuth(), portal()→adminPortal(), rbac()→authorization(), webhook() split) → v7.0 (workos-php v6) → v8.0 (workos-php v7, Laravel 11 dropped) inside roughly four months. Expect breaking-change work at the cadence of the upstream SDK, not of your own roadmap.

Look elsewhere, or skip the wrapper, when:

• You'd rather have one less dependency. The wrapper is genuinely thin — a service provider, facade, helper, config. Binding workos/workos-php yourself is a small amount of code and eliminates a version-coupling hop, letting you track the vendor SDK directly. With 39 stars and no public dependents, the wrapper's ecosystem gravity is low; the official workos-php client is the load-bearing artifact. (Being an official WorkOS-maintained package mitigates the usual abandonment risk — this is not an unmaintained community fork.)
• You're not on Laravel. Use the base PHP SDK.
• You need to self-host identity. WorkOS is SaaS; air-gapped, on-prem, or data-residency-constrained requirements point to Keycloak/Authentik or building on SAML libraries.
• Identity is not on the roadmap at all. Don't add a paid vendor and a fast-moving dependency for a capability nobody is asking for.

Mitigation either way: wrap whichever client you choose behind your own internal interface (e.g. a UserProvisioner / SsoAuthenticator boundary). Then the wrapper-vs-base-SDK question and the v8→v9 upgrade become a single-file change, and the vendor is swappable.

How to Pitch It (Stakeholders)

Executives / GTM: Enterprise deals keep hitting "do you support SAML SSO and SCIM?" Buying WorkOS closes that gap in weeks instead of quarters, and the Admin Portal means our customers' IT teams configure their own IdP — less onboarding hand-holding, fewer support tickets, faster time-to-value on big accounts. The cost is a vendor subscription, offset against the multi-month engineering effort of building and permanently maintaining identity federation ourselves. Compliance wins too: audit logs and centralized de-provisioning are direct inputs to SOC 2.

Engineering: This is the official Laravel SDK for WorkOS, MIT-licensed, maintained by the vendor, with a service provider that gives us a singleton client, a facade, a helper, and DI out of the box — configuration is two environment variables. The tradeoff is honest: it's a thin adapter over workos/workos-php, so we're adding a version-coupling layer, and it moves fast — four majors in recent months, v8 requires Laravel 12 and workos-php v7, with Beta features that can break between betas. We mitigate by pinning versions, reading changelogs before majors, and placing all calls behind our own thin interface so upgrades are contained. If we want to minimize dependencies, we can bind workos/workos-php directly for roughly a day's work — the wrapper's main benefit is convention and less boilerplate, not capability.

The ask: Approve a bounded spike — one engineer, integrate SSO + Admin Portal behind an internal interface, pin the SDK version, and return with a cost/effort estimate for SCIM and RBAC follow-ons and a vendor-lock-in assessment.