Login Cidadao Badges Bundle Laravel Package

Technical Evaluation

Architecture fit — and a material framing correction. The first thing a TPM must flag is that this package is a Symfony bundle, not a Laravel package. It ships a DI extension, registers services into the Symfony container, and hooks into Symfony's security/OAuth2 flow. Laravel shares Symfony components but has no bundle or DI-extension system, so this package cannot be installed into a Laravel application and "just work." The prior assessment in the source material evaluated it as though it were Laravel-native (service provider, Blade/Illuminate API) — that premise is wrong and should be corrected before any estimate leaves the team. The realistic leverage paths are: (1) consume it in a Symfony service that talks to the Laravel app over HTTP, (2) treat it as a reference implementation and port the OAuth2 badge-scope flow into Laravel Socialite or a custom guard, or (3) vendor the badge-claim parsing logic. Path 2 is the most probable.

What it actually does. It wraps the Login Cidadão (PROCERGS, Brazilian government identity) OAuth2 authorization flow so certified profile attributes — verified e-mail, government-issued identity — are requested as badge scopes and returned as claims during authentication. BadgeInterface (introduced in 3.0.0) is the extension seam for consuming those claims. This is identity-adjacent code, which raises the bar on review, pinning, and provenance versus a typical presentation-layer dependency.

Integration feasibility. Low-to-medium, and gated on two independent unknowns. First, framework translation cost: any Laravel leverage requires reimplementing the bundle's wiring, because none of it transfers. Second, the package's last release was October 2018 — roughly seven years stale. A PHP/Symfony artifact of that vintage will almost certainly pin PHP 7.x-era constraints and an old Symfony major, which is a hard blocker against a modern Laravel/Symfony runtime. The "3.0.0 is breaking" concern in the source material is real but secondary; abandonment is the dominant risk, not the interface change.

Technical risk.

• Framework mismatch (high). Bundle ≠ package. No drop-in path to Laravel; budget for a port, not an install.
• Abandonment / staleness (high). Last release 2018, 2 stars, score 0.34. No evidence of active stewardship. Assume no security patching.
• Security surface (high). This is OAuth2 authorization code handling. Stale OAuth2 client code is a genuine vulnerability class — redirect-URI validation, state/PKCE handling, and token validation have all tightened materially since 2018. Any adoption requires a security review, not just a code review.
• Dependency tree (medium-high). 2018-era Symfony/PHP constraints will conflict with a current lockfile and pull unsupported transitives.
• Provenance and jurisdiction (medium). PROCERGS/Login Cidadão is a Brazilian government identity provider. Using it implies a real integration relationship with that IdP — availability, terms, and data-handling obligations are external dependencies the package cannot satisfy on its own.
• Interface change (low-medium). BadgeInterface adoption is breaking, but if we are porting rather than upgrading, it is a design reference, not a migration item.

Key questions.

1. Is there a Laravel consumer anywhere in the org, or is this strictly a Symfony estate? If Laravel-only, this is a reference read, not a dependency decision.
2. What PHP and Symfony versions does 3.0.0 declare, and does it install cleanly against our current runtime at all?
3. Is the Login Cidadão IdP still operated and documented, and do we have (or need) a client registration with PROCERGS? The package is useless without IdP access.
4. Has the repo had any commit, issue response, or security advisory since 2018?
5. What is the actual business requirement — "display verified-identity badges" or "authenticate against Brazilian gov identity"? These have very different build/buy answers.
6. Is there a maintained alternative (e.g., a generic OAuth2/OIDC client plus custom claim mapping) that covers the same requirement without the Symfony coupling?

Confidence is moderate on the framework-mismatch and staleness findings (both are directly observable) and low on the security posture until question 2 is answered.

Integration Approach

Stack fit. Poor as a direct dependency in a Laravel codebase; acceptable as a specification for the OAuth2 badge-scope flow. The concept it encodes — request badge scopes, read certified claims, surface them on the authenticated user — is portable and worth reusing. The wiring is not.

Migration path. Do not attempt to install this into Laravel. Sequence:

1. Requirements spike (one engineer-day). Confirm the business need, confirm IdP access with PROCERGS, and read the bundle's OAuth2 flow end-to-end. Output: a one-page description of the scopes requested and claims returned.
2. Port, don't adopt. Implement the flow against a maintained OAuth2/OIDC client (Socialite provider, league/oauth2-client, or a custom guard). Define a first-party BadgeInterface modelled on theirs so the domain boundary is ours, not the vendor's.
3. Contract tests around claim parsing and badge rendering, so a future IdP change fails loudly in CI.
4. Only if a Symfony service is genuinely in play does the bundle become installable — and then only after a dependency-resolution spike proves it installs on a supported PHP/Symfony pair.

Compatibility. Two axes: (a) package ↔ our PHP/framework pins — almost certainly broken given the 2018 date; (b) package ↔ the live Login Cidadão IdP — unverified and the more consequential of the two. A compatible dependency tree with an incompatible or retired IdP is still a dead end.

Sequencing. Treat as investigation-first, implementation-optional. The one-engineer-day spike above should precede any commitment. If the requirement is real and IdP access exists, collapse into a "build a small OAuth2 badge integration" ticket and cite this package as the reference design. If IdP access does not exist, close the ticket — the package is not the blocker.

Operational Impact

Maintenance. Effectively zero upstream maintenance. A 2018 last release with 2 stars and no visible cadence means we own every line we depend on, including security patches. That is acceptable for a ported reference design; it is not acceptable for a live dependency in an auth path. Assign a named owner regardless.

Support. None assumable. No vendor, no SLA, no evident security disclosure channel. Any production use inherits full support burden internally. The IdP relationship with PROCERGS is a separate support surface and should be confirmed as a business prerequisite, not an engineering afterthought.

Scaling. Badge rendering itself is negligible. The real scaling concerns are (a) OAuth2 round-trips during authentication, which add latency to every login and concentrate load on the IdP — cache claims for the session rather than re-fetching; and (b) claim staleness, since certified attributes change and a cached badge can go out of date. Neither is solved by this package.

Failure modes.

• IdP unavailability. Authentication hard-depends on an external government service. Without a documented fallback (local credentials, graceful degradation), an IdP outage becomes a full login outage.
• Stale OAuth2 implementation. If the bundle's flow is used as-is, 2018-era handling of state, redirect validation, or token verification is a live vulnerability, not a theoretical one.
• Dependency-resolution failure at install. Most likely outcome of trying to add it directly; surfaces early, which is the good case.
• Framework-coupling surprise. An engineer assumes "PHP package, works in Laravel," spends a day, discovers bundles don't apply. Cheap if caught in a spike, expensive if it reaches a sprint commitment.
• Orphaned integration. Ported code with no upstream to track drifts from IdP changes silently; only a contract test catches it.

Ramp-up. A Laravel-fluent engineer with OAuth2 familiarity needs roughly one day to read the bundle and extract the flow, one to two days to implement and test a ported version against a real IdP, plus a security review cycle. Total TPM-level estimate: ~3–4 engineer-days, contingent on IdP access already existing. If PROCERGS registration is required, add external lead time we do not control.

Recommendation. Do not adopt this as a dependency — it is a stale Symfony bundle in a Laravel-targeted evaluation, and the framework mismatch alone disqualifies direct use. Use it as a reference implementation for the Login Cidadão OAuth2 badge-scope flow, fund the one-day requirements/IdP-access spike, and proceed only if the business requirement and the IdP relationship are both confirmed. Correct the record that the prior assessment's Laravel premise was inaccurate before this reaches a roadmap discussion.