Questão de Segurança da Informação — OpenID Connect — FCC 2026

OpenID Connect e OAuth 2.0: fluxos de autenticação para aplicativos móveis

Gabarito: letra B. Para um aplicativo móvel (cliente público), o fluxo mais seguro e recomendado é o Authorization Code com PKCE, no qual o app recebe um código de autorização e o troca por tokens diretamente com o OpenID Provider, permitindo que o backend valide a assinatura e as claims do ID Token antes de associar créditos ao usuário. Essa é a abordagem padrão para apps móveis e SPAs, conforme as boas práticas de OAuth 2.0 e OpenID Connect.

O OpenID Connect (OIDC) é uma camada de autenticação construída sobre o OAuth 2.0. Enquanto o OAuth 2.0 é um protocolo de autorização (concede acesso a recursos), o OIDC adiciona autenticação, introduzindo o ID Token — um JWT que contém claims sobre a identidade do usuário autenticado (como nome, e-mail e um identificador único). O ID Token é entregue ao cliente, que pode interpretá-lo diretamente, ao contrário do access token, que é destinado ao servidor de recursos.

No cenário da questão, o aplicativo móvel é um cliente público: ele não consegue armazenar credenciais com segurança, pois o código pode ser inspecionado. Por isso, o uso de client_secret é inadequado. A solução correta é o Authorization Code Flow com PKCE (Proof Key for Code Exchange), que mitiga a interceptação do código de autorização. O fluxo funciona assim:

1. O app gera um code_verifier (aleatório) e um code_challenge (hash SHA-256 do verifier).

2. O app redireciona o usuário ao endpoint /authorize do OpenID Provider, com response_type=code, client_id, redirect_uri, scope, state, code_challenge e code_challenge_method=S256.

3. O usuário autentica e consente; o provider retorna um code para a redirect_uri.

4. O app troca o code por tokens no endpoint /token, enviando o code_verifier.

5. O provider valida o code_verifier e emite o ID Token, access token e, opcionalmente, refresh token.

6. O backend valida a assinatura e as claims do ID Token antes de associar os créditos de viagem ao usuário.

A alternativa B captura exatamente esse fluxo: o app recebe o código, troca-o por tokens, e o backend valida o ID Token. Isso garante que a identidade autenticada seja obtida de forma segura, sem expor credenciais no app e minimizando o risco de uso indevido de tokens nos validadores.

A pegadinha central da questão é a distinção entre cliente confidencial e cliente público, e entre os fluxos de OAuth 2.0. O candidato pode confundir o Authorization Code Flow (que exige client_secret) com o Authorization Code + PKCE (que não exige, pois o app é público). Além disso, é comum trocar o ID Token pelo access token, ou achar que o fluxo Implicit é adequado para apps móveis — quando ele é desaconselhado justamente por expor tokens na URL de redirecionamento.

Guarde a fronteira entre os fluxos: Authorization Code + PKCE é o padrão para apps móveis e SPAs; Implicit é legado e inseguro; Client Credentials é para máquina a máquina; Resource Owner Password Credentials é restrito e desaconselhado. É exatamente nessa fronteira que as alternativas se dividem.

Alternativa A — ❌ Incorreta

O fluxo Hybrid combina elementos do Authorization Code e do Implicit, mas a alternativa erra ao sugerir que os validadores compartilhem o mesmo client_id e client_secret do app móvel. Isso viola o princípio de que cada cliente deve ter credenciais próprias e, além disso, o app móvel é um cliente público — não deve possuir client_secret. Compartilhar credenciais entre clientes distintos aumenta a superfície de ataque e compromete a segurança.

Alternativa B — ✅ Correta ⟵ GABARITO

Esta é a abordagem correta. O Authorization Code com PKCE é o fluxo recomendado para aplicativos móveis (clientes públicos). O app recebe um código de autorização e o troca por tokens diretamente com o OpenID Provider. O backend valida a assinatura e as claims do ID Token antes de associar créditos ao usuário, garantindo que a identidade autenticada seja confiável. Isso atende a todos os requisitos do enunciado: não expõe credenciais no app e minimiza o risco de uso indevido de tokens.

Alternativa C — ❌ Incorreta

O fluxo Client Credentials é usado para comunicação máquina a máquina, onde o cliente autentica-se com suas próprias credenciais, sem a participação de um usuário. No cenário da questão, é necessário autenticar o usuário para associar créditos de viagem à sua conta. Além disso, a alternativa afirma que não é necessário um ID Token porque o backend já conhece a identidade pelo número do cartão — o que é incorreto, pois a identidade deve ser obtida de forma segura via autenticação, não presumida.

Alternativa D — ❌ Incorreta

O fluxo Implicit é desaconselhado para aplicativos móveis, pois retorna o ID Token diretamente na URL de redirecionamento, expondo-o a riscos de interceptação (por exemplo, via histórico do navegador ou logs). Além disso, distribuir o mesmo ID Token para os validadores reutilizarem durante todo o dia viola a boa prática de tokens de curta duração e aumenta o risco de uso indevido caso o token seja comprometido.

Alternativa E — ❌ Incorreta

Configurar o app móvel como cliente confidencial e armazenar o client_secret no código-fonte é um erro grave: aplicativos móveis são clientes públicos, pois o código pode ser inspecionado e o segredo extraído. O fluxo Resource Owner Password Credentials também é desaconselhado, pois exige que o usuário informe login e senha diretamente ao app, que os encaminha ao provider — isso expõe as credenciais ao cliente e viola o princípio de não compartilhar credenciais.

Gabarito: letra B