Tokens de acesso podem ser obtidos diretamente por public clients (SPAs)?

[glauberferreira]

A solução atual do gov.br suporta que os tokens de acesso sejam obtidos diretamente por public clients, uma SPA por exemplo?

A priori, entendo que sim, dado que a documentação cita no Passo 6 a RFC 7636 - Proof Key for Code Exchange by OAuth Public Clients, que é direcionada para public clients. Entretanto, no mesmo Passo 6, ao descrever os parâmetros para a requisição https://sso.staging.acesso.gov.br/token, existe uma referência para client_secret, o que, no meu entendimento não deveria ser usado por public clients.

Alguém pode me ajudar a esclarecer?

[glauberferreira]

A solução atual do gov.br suporta que os tokens de acesso sejam obtidos diretamente por public clients, uma SPA por exemplo?

A priori, entendo que sim, dado que a documentação cita no Passo 6 a RFC 7636 - Proof Key for Code Exchange by OAuth Public Clients, que é direcionada para public clients. Entretanto, no mesmo Passo 6, ao descrever os parâmetros para a requisição https://sso.staging.acesso.gov.br/token, existe uma referência para client_secret, o que, no meu entendimento não deveria ser usado por public clients.

Alguém pode me ajudar a esclarecer?

Caso de fato seja necessário enviar client_secret a partir da SPA, uma solução arquitetural mais adequada seria esta?

1. Usar o Keycloak para se conectar via Identity Broker ao Gov.Br. O Keycloak atuaria como confidential client, podendo enviar client_secret ao se conectar ao Gov.Br.
2. A SPA obtém token de acesso do Gov.Br a partir do Keycloak, que não exige client_secret ao utilizar PKCE.

[weltonrodrigo]

A resposta curta é: é possível usar um confidential client como se fosse um public client, no caso do gov.br, porque ele não implementa Client Credentials Flow (então a credencial do cliente só serve para obter o token no Authentication Code Flow). Você só não deve por conta da fragilidade de segurança.

A resposta menos curta: provavelmente o gov.br desencoraja isso. Você provavelmente vai estar sujeito às falhas futuras de segurança comuns no browser (XSS, CSRF e outras).

Mesmo para um SPA, é um problema fazer o fluxo openid todo no browser. Por isso tem coisas como o Token Handler Pattern.

No caso do gov.br é o que você provavelmente quer, um pequeno backend para fazer o fluxo OIDC e passar para o token pra aplicação.

Nesse caso, já que você terá um backend (e você provavelmente já teria, já que provavelmente estaria usando o token gov.br para garantir que o usuário é quem diz ser ao acessar uma outra API), é muito melhor você fazer o fluxo gov.br no backend, validar o nível da conta e entregar um token próprio, emitido pela tua própria aplicação. Assim você ganha controle de tempo de sessão, revogação, etc.

Sinceramente, eu ainda não tenho certeza de qual seria a melhor solução, uma vez que o gov.br (ao que parece) não suporta clientes públicos.

Se você não puder mexer na API, o Keycloak com certeza é uma solução possível e tranquila.