| Data de elaboração | 08/06/2026 |
|---|---|
| Responsável pelo estudo | José Lucas da Silva Costa (Analista) |
| Equipe do estudo |
|
| Alvo | Portal do Cidadão |
| Origem | GovBr |
| Objetivo | Estudo técnico para implementação de autenticação via GOV.BR para Pessoa Jurídica no Portal do Cidadão |
| Documentação correlata (opcional) |
https://acesso.gov.br/roteiro-tecnico/iniciarintegracao.html https://wiki.setic.ro.gov.br/pt-br/home/spaces/code/gc/padroes |
| Observações | Nenhuma |
Investigar como o Portal do Cidadão pode suportar a atuação de usuários como representantes de pessoa jurídica, usando o GOV.BR como autenticador, e levantar as histórias de usuário que subsidiem a implementação pela equipe de desenvolvimento.
O Portal do Cidadão precisa evoluir para atender cenários onde o solicitante não é um cidadão agindo em nome próprio, mas sim um representante de uma empresa ou de um órgão público de outro poder. Essa necessidade surgiu de demandas G2E (governo para empresa) e G2G (governo para governo).
A primeira pergunta levantada pelo time foi: é possível fazer login diretamente com CNPJ no GOV.BR? A resposta é não. O GOV.BR autentica exclusivamente pessoas físicas via CPF. O CNPJ não é uma credencial de acesso, ele é um atributo que pode ser associado a uma sessão após o login. Essa distinção é o ponto central deste estudo.
A partir daí, o estudo examinou os dois caminhos que o GOV.BR oferece para associar um CNPJ a uma sessão autenticada, e avaliou três cenários concretos levantados pelo time: empresas privadas, empresas/órgãos sem vínculo formal, e servidores públicos de outros poderes.
Limitação: este caminho exige que o usuário possua um e-CNPJ. Nem toda empresa tem certificado digital (MEIs), empresas do Simples e boa parte das pequenas empresas operam sem ele. Para servidores públicos representando órgãos, a situação é ainda mais restrita.
Por esse motivo, este caminho é tecnicamente possível mas não viável como solução principal. Pode ser suportado como complementar para usuários que já dispõem do e-CNPJ.
Existem dois caminhos documentados. Eles não são excludentes, podem coexistir no portal como opções complementares.
3.1 Login com CPF + escopo govbr_empresa (caminho principal)
O usuário loga normalmente com CPF e senha no GOV.BR. O portal, ao montar a requisição de autenticação, inclui o escopo govbr_empresa. Com isso, após o login, o portal pode chamar a API de empresas do GOV.BR usando o access_token da sessão:
GET /empresas/v2/empresas?filtrar-por-participante=cpf
Retorno:
{
"cnpj": "12345678000195",
"razaoSocial": "Empresa Exemplo LTDA",
"atuacao": "SOCIO"
}
O campo atuacao indica o papel do CPF naquela empresa. Os valores possíveis são:
O dado não vem do GOV.BR em si , o GOV.BR consulta a Receita Federal em tempo real. Não é possível forjar um vínculo: ou está na RFB ou não está.
Este é o caminho recomendado. Não exige que o usuário tenha certificado digital, funciona com qualquer conta GOV.BR nível Prata ou Ouro, e já é o modelo adotado por outros portais estaduais.
3.2 Login com certificado digital de pessoa jurídica (e-CNPJ)
Quando o usuário autentica no GOV.BR usando um certificado digital de pessoa jurídica, o token OIDC retornado já inclui o claim cnpj diretamente. O portal lê esse claim sem precisar chamar a API de empresas.
Observação: este caminho exige que o usuário possua um e-CNPJ. Nem toda empresa tem certificado digital
4.1 Empresa privada
A premissa levantada no time de que toda empresa privada teria e-CNPJ não se sustenta. Uma parcela significativa das empresas ativas no Brasil, especialmente MEIs e empresas do Simples Nacional com poucos funcionários, não possui certificado digital.
Ainda assim, esse cenário é o mais simples de resolver. Sócios, representantes legais e contadores aparecem automaticamente na consulta via govbr_empresa, sem necessidade de nenhuma ação prévia da empresa no portal. O vínculo já existe na Receita Federal.
4.2 Empresa ou CNPJ sem vínculo formal na Receita Federal
Se o CPF do usuário não aparece vinculado ao CNPJ na consulta via govbr_empresa, o portal não tem base para autorizar a representação. Aceitar autodeclaração ou seja, o usuário simplesmente informar um CNPJ e o portal confiar cria risco jurídico real: o portal pode processar solicitações em nome de uma empresa a pedido de alguém que não tem legitimidade para isso.
O fluxo correto para esse caso é negar o contexto PJ e orientar o usuário. O GOV.BR oferece um mecanismo para isso: o responsável legal da empresa usa o e-CNPJ para cadastrar colaboradores, que passam a aparecer com atuacao COLABORADOR na API. O portal não precisa resolver esse problema, precisa comunicar bem o caminho de regularização.
Importante: O portal não deve aceitar representação de CNPJ sem vínculo confirmado via GOV.BR. A orientação ao usuário deve ser clara: regularizar o vínculo acessando o GOV.BR com o responsável legal da empresa.
4.3 Servidor público de outro poder
Este é o cenário mais diferente. Um servidor não representa um CNPJ como sócio ou procurador, ele age como agente público, e o vínculo é funcional, não societário. A Receita não tem esse dado, então o govbr_empresa não serve aqui.
A solução identificada pelo time está relacionada a uma funcionalidade em desenvolvimento do E-Estado: um módulo de organograma que suportará órgãos externos ao Governo de Rondônia. Se esse módulo cadastrar os servidores e seus vínculos institucionais, o Portão do Cidadão pode consultá-lo após o login da mesma forma que consultaria a API de empresas para verificar se o CPF autenticado tem vínculo com algum órgão e em qual papel.
Esse caminho ainda depende da entrega do organograma externo. Enquanto não estiver disponível, o cenário de servidor de outro poder não tem solução via portal.
O portal já tem a base para implementar o fluxo do govbr_empresa sem grandes mudanças estruturais. Os escopos solicitados hoje ao GOV.BR no Program.cs são:
options.Scope.Add("openid");
options.Scope.Add("email");
options.Scope.Add("profile");
// govbr_empresa: ausente
O GovBrClaimsHandler já existe e já é o ponto onde claims customizados são processados após o login, hoje ele adiciona o claim termo_aceite_portal_cidadao. O mesmo mecanismo serviria para consultar a API de empresas e registrar os CNPJs na sessão.
O GovBrAuthorizationHandler já propaga o access_token para chamadas às APIs do GOV.BR. O IGovBrClient, também existente, precisaria de um novo endpoint para a API de empresas.
O padrão de manipulação de claims na sessão AddClaim, RemoveClaim, SignInAsync já é usado no AutenticacaoController para o termo de aceite. O contexto de CNPJ seguiria o mesmo padrão.
As histórias abaixo cobrem o caminho principal (govbr_empresa). O cenário de servidores de outros poderes não entra aqui por depender de entrega externa.
História 01 - Incluir escopo govbr_empresa na autenticação
Eu, como Portal do Cidadão, devo solicitar o escopo govbr_empresa ao GOV.BR na requisição de autenticação quando o serviço acessado exigir contexto de pessoa jurídica, para que o access_token obtido permita consultar os CNPJs vinculados ao CPF autenticado.
Regras:
Cenários:
História 02 - Consultar CNPJs vinculados ao CPF após o login
Eu, como Portal do Cidadão, devo chamar a API de empresas do GOV.BR após a validação do token e registrar os CNPJs vinculados na sessão, para que o portal saiba quais CNPJs o usuário pode representar antes de apresentar a tela de seleção.
Regras:
Cenários:
História 03 - Apresentar tela de seleção de contexto
Eu, como usuário com ao menos um CNPJ vinculado, devo visualizar uma tela de seleção após o login para escolher se quero atuar como pessoa física ou em nome de um CNPJ, para que o portal aplique as regras de acesso e negócio correspondentes ao contexto escolhido.
Regras:
Cenários:
História 04 - Registrar contexto PJ na sessão via claims
Eu, como Portal do Cidadão, devo adicionar os claims cnpj_contexto e papel_cnpj à identidade da sessão quando o usuário selecionar um CNPJ, para que os controllers e serviços downstream identifiquem o contexto ativo sem precisar consultar a API GOV.BR a cada requisição.
Regras:
Cenários:
Dois pontos não estão cobertos pelas histórias acima porque dependem de decisões ou entregas externas:
O GOV.BR não autentica CNPJ. A autenticação é sempre por CPF, e o CNPJ é um contexto que se associa à sessão depois do login.
O caminho viável para o portal é o escopo govbr_empresa : o usuário loga com CPF normalmente, o portal consulta a API do GOV.BR, que por sua vez consulta a Receita Federal, e retorna os CNPJs que aquele CPF representa. Sem certificado digital, sem nenhuma ação prévia da empresa no portal.
O certificado digital (e-CNPJ) funciona, mas não resolve o problema todo, boa parte das empresas não tem, e servidores públicos representando órgãos não se enquadram nesse modelo de qualquer forma.
Para empresas privadas cujo representante não aparece vinculado na RFB, o portal não tem o que fazer além de orientar: o responsável legal precisa regularizar o vínculo pelo GOV.BR. Aceitar autodeclaração não é uma opção segura do ponto de vista jurídico.
Para servidores de outros poderes, a solução depende do módulo de organograma externo que está em desenvolvimento. Quando estiver disponível, o fluxo será o mesmo, só muda a fonte de consulta do vínculo. Até lá, esse cenário não tem cobertura.