Laravel Sso Laravel Package

Product Decisions This Supports

• Build vs. buy for enterprise SSO: This package is a strong candidate to buy (adopt) rather than build if your customers or internal users authenticate through Microsoft Entra ID via the Postiefs SSO portal. It removes the need to implement launch-token verification, session-deadline enforcement, and portal session checks in-house.
• Feature: SSO/enterprise sign-in: Enables a "Sign in with Postiefs" flow with portal-controlled session lifetimes — a common enterprise procurement checkbox. The sexp deadline is adopted and never extended, which is a deliberate product stance on session control.
• Roadmap: session governance and forced sign-out: Because access is re-checked against the portal at most every check_interval seconds (and users stay signed in if the portal is down), you get near-real-time revocation with graceful degradation. Suitable for compliance-sensitive products where access must be withdrawn centrally.
• Build vs. buy for user provisioning: The UserResolver contract (default: find-or-create by email, never mutate existing users) lets you keep your own user model and permission system; roles remain in your app (e.g. spatie/laravel-permission). This reduces migration and data-ownership risk — a meaningful plus in buy-vs-build evaluations.
• Use cases: B2B SaaS with Entra ID tenants, internal tools behind a corporate portal, and any product needing centrally managed sessions without maintaining an identity provider.
• Operational decisions: sso:check and sso:install lower setup cost and give a health/diagnostic path; events (SsoUserCreated, SsoLoggedIn, SsoSessionEnded) and the Sso facade support audit logging and analytics without forking the package. The browser guard (@ssoSessionGuard) supports UX decisions around deadline warnings and heartbeat-driven expiry.
• Scope/risk: No migrations and no schema coupling mean low rollout cost and easy reversibility if you later move to another IdP.

When to Consider This Package

Adopt when:

• Your identity path is Microsoft Entra ID through the Postiefs SSO portal — the package is purpose-built for that portal's launch tokens and /auth/check-access endpoint, so it is not a general-purpose OIDC/SAML client.
• You are on PHP 8.2+ and Laravel 11, 12, or 13.
• You want portal-controlled sessions with a hard deadline that cannot be extended locally.
• You need to keep users and roles in your own application and only delegate authentication.
• You want minimal footprint: no migrations, no new tables, installable via sso:install.

Look elsewhere when:

• You need a generic SSO solution for multiple IdPs (Okta, Auth0, Google, generic SAML/OIDC) — this is single-portal.
• You require offline-first or fully portal-independent session validation.
• You need the package to manage roles/permissions or user profile synchronization — it deliberately does not.
• You need strict fail-closed behavior when the portal is unavailable: the design keeps users signed in during outages, which may conflict with high-assurance policy.
• You cannot accept v1.0.0 maturity risk (first release, small surface area, limited production track record).

How to Pitch It (Stakeholders)

For executives: This package gives us enterprise single sign-on through the Postiefs portal and Microsoft Entra ID in one integration instead of a custom build. Sessions are controlled centrally — access can be revoked at the portal, and the local session cannot outlive the portal's deadline. It adds no database changes and no new source of truth for users or roles, so our data model and permission system stay ours. Time-to-value is short (composer require plus one install command), and the main dependency is a first-release package from a single provider.

For engineering: Laravel 11–13 / PHP 8.2+ package with a launch-token verification flow (HS256, issuer, audience, expiry, single use), a session check against the portal throttled to check_interval with fail-open behavior during portal outages, and callback/login/ended/heartbeat/logout routes protected by sso, sso.auth, and sso.session middleware. Extensibility is via the UserResolver contract, events, and the Sso facade; there is a LaunchToken test helper, a @ssoSessionGuard Blade directive for client-side deadline handling, sso:install / sso:check commands, and handling for stray tokens from a misconfigured Callback URL. No migrations, no schema changes. Risks to validate before GA: single-use token semantics under retries, fail-open window during portal downtime versus our security policy, heartbeat load, and v1.0.0 maturity — recommend a spike plus documented fallback to direct Entra ID integration if the package does not hold up.