Login Cidadao Badges Bundle Laravel Package

Product Decisions This Supports

• Identity-proofing / KYC-lite build-vs-buy. The package wraps the Login Cidadão OAuth2 flow so certified profile attributes — verified e-mail, government-issued identity — can be requested as scopes and consumed at login. The product decision it informs is whether we outsource "trusted identity claims" to a government-backed IdP or build our own verification pipeline. For a Brazilian-market product, that is a real strategic fork, not a cosmetic feature.
• Target-market and IdP strategy. Adopting this only makes sense if Login Cidadão (PROCERGS, Rio Grande do Sul) is a first-class identity provider in our roadmap. That decision — which IdPs we support — is a PM call with go-to-market implications: it unlocks a specific Brazilian user base and a specific trust story, and it commits us to that ecosystem's availability and policy.
• Framework commitment. The package is a Symfony bundle, not a Laravel package. If our stack is Laravel (as the brief frames it), the real roadmap item is "port/wrap this bundle's logic" — a build decision, not a composer require. That reframes cost from an install to a small integration project and belongs in the estimate, not an engineer's afternoon.
• Dependency-risk posture. Two stars, last release October 2018, and a one-line changelog. This is the archetype of an "adopt only with an exit plan" dependency. It should be decided against a written policy for unmaintained/single-maintainer packages rather than case-by-case, because the pattern will recur.
• Scope validation for "login with gov ID" requests. When a stakeholder asks for verified-identity sign-in, having this as a reference implementation lets us price the request as integration + compliance review rather than net-new R&D.
• Compliance and data-handling decisions. Consuming government-issued identity claims pulls in LGPD/GDPR-adjacent questions: what we store, for how long, and what "verified" legally means in our jurisdiction. That is a PM/legal decision the technical choice forces into the open.

When to Consider This Package

Consider it when:

• The application is Symfony (the bundle targets Symfony's DI container and security stack). On Laravel, treat it as a reference design, not a drop-in.
• Login Cidadão / PROCERGS is an intended IdP for a Brazilian user base, and certified claims (verified e-mail, gov identity) are a genuine product requirement rather than a "nice to have."
• We need OAuth2 badge scopes wired into authentication and are willing to own the code. Given the 2018 release cadence, assume we will fork or vendor it and maintain it ourselves.
• The integration surface is narrow and presentation/identity-scoped — no schema, queue, or persistence coupling — so the blast radius of abandonment stays small.
• We have an engineer who can read the badge contract and the OAuth flow and stand behind it. This is not a "set and forget" dependency.

Look elsewhere when:

• The stack is Laravel. There is no Laravel service provider here; the "Laravel/PHP package" framing is inaccurate. Budget a port, or use a maintained OAuth2 client plus custom claim handling instead.
• The identity provider is not Login Cidadão. The value is entirely in the PROCERGS-specific badge scope semantics. For generic OIDC/OAuth2 (Auth0, Keycloak, Google, Gov.br via standard OIDC), use a maintained client and skip this.
• Maintenance is a hard requirement. No releases since 2018 and near-zero community signal means no security-response channel, no support matrix, and no compatibility guarantees. If our policy forbids unmaintained dependencies, this fails on day one.
• We need audited, current security posture. An OAuth2-adjacent library that hasn't shipped in years is a poor place to inherit cryptographic/flow assumptions we can't verify.
• "Verified identity" is core IP. If trust and verification are how we differentiate, consuming someone else's badge semantics outsources the core model.

PM action before commitment: get a one-page spike answering (a) does the badge contract and OAuth flow still work against the current Login Cidadão endpoints, (b) what does the Symfony-version/PHP-floor support look like, and (c) what is our fork-and-own cost. Do not commit roadmap dates before that exists.

How to Pitch It (Stakeholders)

To executives: This is a small, single-purpose integration that lets us accept government-certified identity badges from Login Cidadão — verified e-mail and government-issued ID — during sign-in, instead of building identity verification ourselves. That is strategically useful only if Login Cidadão is a market we intend to serve; otherwise it is a niche dependency. The material caveats are that it is a Symfony bundle (our Laravel stack would need a port), it has had no release since 2018, and it has effectively no community. Recommendation: treat it as a reference implementation to adapt, not a dependency to adopt. If Brazilian identity is on the roadmap, fund a short spike to confirm the flow still works and to price a fork we own; if it is not, close the question.

To engineering: The package is a Symfony bundle wiring Login Cidadão's OAuth2 badge scopes into authentication and exposing certified claims to security/user providers. On Laravel, expect to reimplement the OAuth2 claim handling behind our own auth adapter — do not try to shoehorn Symfony DI into the app. Before any code: verify the badge scopes and claim shapes against live Login Cidadão endpoints, confirm supported PHP/Symfony versions, and check whether the repo has a security disclosure path. Assume we own maintenance; keep the integration behind a first-party interface so the vendor code is replaceable, add contract tests around the claims we actually consume, and log/validate every claim rather than trusting it implicitly. Come back with an explicit build-vs-fork-vs-skip recommendation and an effort estimate before we put this on a release.