Saml2 Laravel Package

Product Decisions This Supports

• Enterprise SSO as a sellable feature. SAML2 support is a checklist item for B2B/enterprise buyers (Okta, Azure AD, ADFS). This package is the cheapest path to "we support your IdP" in a Laravel product, which directly unblocks enterprise procurement and security reviews.
• Build vs. buy on identity. SAML is deceptively hard: XML canonicalization, signature validation, cert rotation, clock skew, assertion replay, SP/IdP metadata exchange. Adopting a driver means the team owns configuration and mapping, not cryptographic correctness — a materially smaller and lower-risk scope.
• Roadmap sequencing for auth. Because it plugs into Laravel Socialite, SAML becomes an incremental provider alongside Google/GitHub/Apple logins rather than a parallel auth subsystem. That lets you sequence SSO after core auth without a rewrite.
• Use cases it fits: employee/partner portals, internal admin tooling behind corporate IdP, multi-tenant SaaS where each customer brings its own IdP, and regulated buyers who forbid password-based login.
• Decisions it does not make for you (product must still resolve): JIT user provisioning vs. invite-only, attribute-to-role/tenant mapping, multi-IdP-per-tenant routing, session/logout semantics, and account-linking between SAML and existing password/social identities.
• Explicitly out of scope: SCIM/directory sync, deprovisioning, and group-based authorization. If enterprise buyers expect those, budget them as separate roadmap items rather than assuming SSO covers "enterprise identity."

When to Consider This Package

Adopt when:

• The app is Laravel and already on Laravel Socialite — the value proposition is preserving that redirect/callback/user() contract.
• You have one or a few known IdPs and standard SP-initiated SSO, not exotic flows (encrypted assertions, strict SLO, complex attribute statements).
• Your team has no dedicated identity engineer and building/auditing a SAML SP is not a good use of the quarter.
• You can absorb a community-maintained dependency: 17 stars and a thin contributor base means real bus-factor and CVE-response risk. Require a security review of the code path, pin the version, subscribe to advisories, and confirm the release cadence before committing.

Look elsewhere when:

• You need a supported vendor with an SLA (SOC2/FedRAMP buyers often demand this) — evaluate managed IdP brokers such as WorkOS/Auth0/Keycloak instead.
• Requirements include SCIM provisioning, per-tenant IdP routing at scale, adaptive MFA, or audit logging — those are platform problems, not a Socialite driver.
• The stack isn't Laravel/Socialite, or you'd rather standardize on OIDC (Azure AD and Okta both do OIDC well, with far less XML).
• You need custom assertion parsing or non-standard bindings deep enough that you'd end up forking the package anyway — at that point own the integration deliberately.

How to Pitch It (Stakeholders)

To executives (business case): "Enterprise deals stall on SSO. This package adds SAML2 login — the mechanism Okta, Azure AD, and ADFS use — to our existing Laravel auth in days rather than the months a custom build would take, and without touching our current login system. It's a small, low-cost integration that removes a recurring procurement blocker. The trade-off: it's a community package with a small user base, so I'd pair adoption with a dependency review, a pinned version, and a documented fallback — not treat it as a permanent strategic commitment."

To engineering (delivery): "It's a drop-in Socialite provider. We configure SP/IdP metadata, endpoints, and certificates; the package handles redirect/callback and parses assertions into a Socialite user, so our auth code stays uniform across providers. What we own: certificate rotation, attribute-to-role/tenant mapping, JIT provisioning rules, test IdP tenants, and monitoring the upstream package for security fixes. Budget roughly a sprint for integration plus a hardening pass; flag any IdP requiring encrypted assertions or non-standard flows early, since those may push us off this package."

Recommendation: adopt behind a feature flag for one design-partner customer to validate the flow end-to-end; keep the integration thin (a service class around the provider) so swapping to a managed IdP vendor later is a contained change, not a rewrite.