- Can I install mainick/keycloak-client-bundle in a Laravel app with Composer?
- You can run composer require mainick/keycloak-client-bundle in a Laravel project and it will usually resolve, because Laravel already pulls in Symfony components such as http-foundation and console. What you get, however, is a Symfony Bundle that expects bundle registration, a DI Extension compile pass, and a kernel.request listener. Laravel has none of those hooks, so the package will install without ever doing anything useful. Treat installation as a code-vendoring step, not an integration.
- What does this Keycloak bundle actually do?
- It is a Symfony bundle that adds OpenID Connect single sign-on against Keycloak, covering login, logout, token acquisition and refresh, and user information access. It also registers a request listener that validates the token on every incoming request. Role-based access and route or API protection are handled through Symfony's security layer with minimal configuration.
- Why can't Laravel use a Symfony bundle directly?
- A Symfony bundle plugs into mechanisms Laravel does not implement: bundle registration in the kernel, container Extension classes that compile service definitions from YAML or XML, and event subscribers bound to HttpKernel events like kernel.request. Laravel's equivalent surfaces are service providers, the service container, and HTTP middleware, and none of them are wire-compatible. That means the entire integration layer of this package has to be rewritten rather than reused.
- Is the Keycloak client logic reusable outside Symfony?
- Only if the token handling, JWKS processing, and userinfo mapping live in a framework-agnostic core that the bundle merely wraps. If that logic is entangled with Symfony HTTP and DI classes, you are effectively vendoring and refactoring the code rather than adopting it. Confirm this before design freeze by installing the package standalone and checking whether anything works without HttpKernel or the Symfony container.
- How would I add Keycloak SSO to Laravel if the bundle doesn't fit?
- Reimplement the thin Laravel-facing layer yourself: a service provider for configuration binding, a guard or user provider plus middleware for authentication, and a cache-backed verifier for Keycloak's JWKS endpoint. Keep the token acquisition and claim mapping logic in a small, testable class you own. The reimplementation is modest, but note that key rotation, clock skew tolerance, and audience and issuer checks then become your code and your review burden.
- Which Keycloak flows does it support: authorization code with PKCE, client credentials, refresh, and logout?
- The package advertises login, logout, token management, and refresh, with OpenID Connect as the underlying protocol, but the documentation excerpt does not enumerate supported grants. Before committing, verify whether authorization code with PKCE, client credentials, password grant, RP-initiated logout, and backchannel logout are all covered. Backchannel logout in particular matters if you need sessions invalidated across multiple applications.
- How are Keycloak roles mapped to Laravel users and gates?
- In Symfony, the bundle maps realm and client roles into security principals through its own configuration. Laravel has no equivalent principal model, so that mapping must be replaced with your own user provider or gate and policy definitions. The key question for a spike is whether the claim-to-role transformation is configurable or hardcoded; if it is hardcoded, plan to intercept and remap claims in your own middleware.
- Does it support multiple realms or guards, like separate admin and customer realms in one app?
- This is not documented in the overview and should be treated as an open question. Multi-realm support matters if you run distinct admin and customer Keycloak realms against a single application and need independent guards. In a Laravel port you would model this with multiple guards and separate configuration blocks, but only if the underlying client can hold more than one realm configuration at a time.
- Does it validate tokens locally with JWKS or call Keycloak introspection on every request?
- The bundle includes a listener that verifies the token on every request, but the overview does not state whether verification is local signature validation against JWKS or remote introspection. The distinction changes your failure model substantially: local JWKS validation can be cached and survives Keycloak downtime, while per-request introspection makes Keycloak a hard runtime dependency. Also check the JWKS cache TTL and how key rotation is handled if you re-host this logic in Laravel.
- Is it production-ready and actively maintained for authentication use?
- The project has roughly 45 GitHub stars and no known dependents, and it appears to be maintained by a single author, which means thin security-response capacity for a component that sits in your authentication path. There is no evidence the request-listener path has run under production load, and certainly not in a Laravel-shaped application. Verify the release cadence and the CVE disclosure process, and prefer established alternatives or a small in-house implementation you can fork and own if the maintainer steps away.