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

OpenID Connect: o ID Token como prova de autenticação

Gabarito: letra E. No OpenID Connect (OIDC), o artefato que corresponde à prova verificável de autenticação é o ID Token, estruturado como um JSON Web Token (JWT) assinado pelo Provedor de Identidade (IdP). Ele carrega as claims sobre o usuário autenticado (sub, name, email, auth_time, etc.) e é entregue ao cliente, que pode interpretá-lo diretamente — diferentemente do Access Token, que é opaco para o cliente e serve apenas para acessar recursos protegidos.

O OpenID Connect é uma camada de autenticação construída sobre o protocolo OAuth 2.0, que é um protocolo de autorização. Enquanto o OAuth 2.0 puro emite tokens de acesso para que um cliente acesse recursos em nome do usuário, o OIDC adiciona a capacidade de autenticar o usuário, ou seja, provar quem ele é. Essa prova é materializada no ID Token, um JWT assinado pelo Authorization Server (que, no contexto OIDC, atua como Provedor de Identidade). A assinatura garante a integridade e a autenticidade do token: o cliente pode verificar a assinatura usando a chave pública do IdP e, assim, confiar nas claims contidas no payload.

O ID Token contém claims como sub (identificador único do usuário), name, email, auth_time (momento da autenticação), acr (nível de autenticação), amr (métodos de autenticação usados), além de metadados como iss (emissor), aud (audiência), exp (expiração), iat (emissão) e nonce (para prevenir replay). É justamente essa estrutura que o torna uma prova verificável: o cliente valida a assinatura, o emissor, a audiência e a expiração, e então sabe que o usuário foi autenticado pelo IdP naquele momento.

Na prática, imagine um Ministério Público Estadual que adota OIDC para unificar o acesso aos seus sistemas. Quando um promotor acessa o sistema administrativo, ele é redirecionado ao IdP (por exemplo, um Keycloak), que autentica o usuário (talvez com MFA) e emite um ID Token assinado. O sistema cliente recebe esse ID Token, valida a assinatura e as claims, e então sabe que o usuário é o promotor X, autenticado naquele momento. Só depois disso a aplicação cliente decide quais autorizações conceder (por exemplo, quais processos ele pode visualizar).

A distinção crucial que a banca explora é entre ID Token e Access Token. O ID Token é voltado à identificação (quem é o usuário), é interpretado pelo cliente e não serve para acessar recursos. O Access Token é voltado à autorização (o que o usuário pode acessar), é interpretado pelo servidor de recursos e o cliente não deve interpretá-lo. Essa fronteira é exatamente o que separa a alternativa correta das demais.

Alternativa A — ❌ Incorreta

O Authorization Code é um código temporário retornado pelo endpoint de autorização, usado na troca por tokens no endpoint de token. Ele não é a prova de autenticação em si, mas sim um intermediário no fluxo de autorização. No OIDC, após a troca do código, o cliente recebe o ID Token (e o Access Token). O código não carrega claims sobre o usuário e não é assinado como um JWT.

Alternativa B — ❌ Incorreta

O UserInfo Endpoint retorna claims sobre o usuário, mas essas claims são obtidas após a autenticação, usando o Access Token. O UserInfo Endpoint é um complemento ao ID Token, mas não é a prova de autenticação em si. Além disso, as claims retornadas não são assinadas como um JWT (embora possam ser, opcionalmente), e o ID Token já contém as claims essenciais do usuário.

Alternativa C — ❌ Incorreta

O Access Token é emitido pelo Authorization Server para acesso a recursos protegidos nas APIs. Ele representa uma autorização concedida, não a prova de autenticação. O cliente não deve interpretar o Access Token (ele é opaco ou, se JWT, deve ser validado apenas pelo Resource Server). A prova de autenticação no OIDC é o ID Token, não o Access Token.

Alternativa D — ❌ Incorreta

O Refresh Token é usado para obter novos Access Tokens sem exigir nova autenticação do usuário. Ele é um mecanismo de conveniência e segurança, mas não é a prova de autenticação. O Refresh Token é enviado apenas ao Authorization Server e nunca ao Resource Server. Ele não contém claims sobre o usuário e não é assinado como um JWT.

Alternativa E — ✅ Correta ⟵ GABARITO

O ID Token é exatamente a prova verificável de autenticação no OIDC. Ele é um JWT assinado pelo Provedor de Identidade, contendo claims sobre o usuário autenticado e sobre a autenticação em si (auth_time, acr, amr). O cliente pode validar a assinatura e as claims, garantindo que o usuário foi autenticado pelo IdP. Essa é a definição central do OIDC: o ID Token é a extensão que adiciona autenticação ao OAuth 2.0.

Gabarito: letra E