Laravel Keycloak Web Guard Laravel Package

Product Decisions This Supports

• SSO / enterprise identity as a feature, not a project. If a customer or internal stakeholder asks "can we log in with our company Keycloak?", this package is a short path to answering yes on browser-based (session) routes. That directly supports deals gated on SSO/OIDC support.
• Build vs. buy vs. borrow. The realistic alternative is writing a custom OIDC client, wiring token validation, session handling, and role mapping yourself — roughly days-to-weeks of engineering plus ongoing ownership. This package collapses that into configuration plus a role-mapping decision, so it shifts the decision from "build a feature" to "evaluate a dependency."
• Roadmap sequencing for a "B2B / enterprise tier." Adopting it early lets you ship SSO behind a flag and defer the harder questions (multi-tenant IdP per customer, SCIM provisioning, fine-grained authorization) until revenue justifies them.
• Authorization model decisions. Because it maps Keycloak roles into Laravel's guard/gates, it forces an explicit decision on where permissions live — Keycloak realm/client roles vs. application-side policies. That decision is worth making deliberately; teams that skip it end up with role logic split across two systems.
• Use cases it fits: internal admin dashboards, partner/back-office portals, and any Laravel app inside an organization that has already standardized on Keycloak. It is a poor fit as the identity layer for a consumer product or a security-critical surface.
• Risk appetite as a decision input. This package is archived — no maintainer, no security patches, no Laravel-version compatibility guarantees. Adopting it is a decision to own the code, not to consume a product. That trade is reasonable for a small internal tool with a fork-and-pin plan; it is not reasonable for a flagship, externally facing auth surface.

When to Consider This Package

Consider it when all of the following hold:

• Keycloak is already the organizational IdP and is not up for debate.
• The surface is Laravel web routes with session-based auth, not a stateless API (the sibling API-guard packages are the relevant comparison there).
• You need Keycloak roles reflected as Laravel authorization, not just "logged in / not logged in."
• The app is internal, low-blast-radius, or otherwise tolerant of a dependency you will own.
• Your team is prepared to vendor or fork the package, pin it, and audit it at each Laravel upgrade.

Look elsewhere when any of these are true:

• Maintenance matters — user-facing auth, compliance scope, or a multi-year support commitment. Archived dependencies in the auth path are a recurring audit finding and a slow-motion incident.
• You need modern OIDC semantics: PKCE, token refresh/rotation, back-channel or RP-initiated logout, session revocation, or precise claim/scope control.
• You need SAML, multiple IdPs per tenant, or SCIM provisioning.
• Your Laravel/PHP versions have moved past what the package ever supported — verify this before anything else, since an archived package's compatibility ceiling is fixed.
• The requirement is really API/machine-to-machine auth, where a token guard plus a maintained OIDC library is the better shape.

The pragmatic middle path: use it as a reference implementation for how Keycloak maps onto Laravel's web guard, then either fork it or reimplement the ~few hundred relevant lines against a maintained OIDC library. Many teams get more value from reading it than depending on it.

How to Pitch It (Stakeholders)

To executives: This is a small, cheap way to unblock "log in with our company identity provider" for a Laravel app in an organization already using Keycloak — measured in days rather than a quarter, with role-based access included. The caveat to state plainly: the package is archived, so we would own it. Treat it as a bridge to validate demand, not a permanent foundation, and budget a follow-up to replace or fork it if SSO becomes a committed, customer-facing capability.

To engineering: It wires Keycloak into Laravel's web guard and maps Keycloak roles to Laravel authorization, removing the custom OIDC-client work. Two non-negotiables before adoption: (1) confirm compatibility with our Laravel/PHP versions against a frozen codebase, and (2) vendor or fork it into our repo with a named owner, because there will be no upstream fixes. Scope it to one internal surface first; if the pattern proves out, we invest in a maintained implementation rather than spreading an unmaintained auth dependency across the product.