Questão de Segurança da Informação — Gestão de Identidade e Acesso (IAM, IdP e Identidade Federada) — FCC 2025

OAuth 2.0 e o Keycloak como Authorization Server

Gabarito: letra A. O Keycloak, ao ser utilizado como Identity Provider (IdP), atua como Authorization Server no fluxo OAuth 2.0, sendo responsável por autenticar os usuários e emitir access tokens e refresh tokens para as aplicações cliente — exatamente o que a alternativa A descreve. As demais alternativas distorcem conceitos centrais do protocolo, como o papel do Keycloak, a segurança dos fluxos de autorização e a função dos tokens.

O OAuth 2.0 é um protocolo de autorização, não de autenticação. Ele permite que uma aplicação (cliente) acesse recursos protegidos em nome de um usuário (resource owner) sem que as credenciais deste sejam expostas. Para isso, o protocolo define quatro atores principais: o resource owner (dono dos dados), o client (aplicação que deseja acessar os recursos), o authorization server (servidor que autentica o usuário e emite tokens) e o resource server (servidor que armazena os dados protegidos e valida os tokens). O Keycloak, nesse cenário, desempenha o papel de authorization server, centralizando a autenticação e a emissão de tokens para os diversos aplicativos do tribunal.

O protocolo define diferentes fluxos de autorização (grants), cada um com características e níveis de segurança específicos. O Authorization Code Flow é o mais seguro e recomendado para aplicações web, pois o access token nunca é exposto diretamente ao navegador do usuário — a aplicação troca um código de autorização pelo token em um canal seguro. O Implicit Flow, por outro lado, é considerado menos seguro, pois o token é retornado diretamente na URL de redirecionamento, sendo desaconselhado para aplicações modernas. O Client Credentials Flow é utilizado para comunicação máquina a máquina, sem a intervenção de um usuário. Já o Resource Owner Password Credentials Flow é restrito e menos seguro, pois exige que o usuário forneça suas credenciais diretamente à aplicação.

Os tokens são o coração do OAuth 2.0. O access token é usado para acessar recursos protegidos no resource server. O refresh token permite obter novos access tokens sem que o usuário precise se autenticar novamente, mantendo a sessão ativa. O ID token, por sua vez, é uma extensão do OpenID Connect (OIDC), uma camada de autenticação construída sobre o OAuth 2.0, e contém informações sobre a identidade do usuário autenticado. É importante destacar que o OAuth 2.0, por si só, não emite ID tokens — essa é uma funcionalidade do OIDC.

A banca explora, nesta questão, a confusão entre os papéis do Keycloak, os fluxos de autorização e os tipos de tokens. A alternativa correta reconhece o papel central do Keycloak como authorization server. As alternativas incorretas, por sua vez, apresentam afirmações falsas sobre o suporte a OAuth2, a segurança do Implicit Flow, a existência de fluxos inexistentes e a capacidade de emitir refresh tokens. Para resolver a questão, é fundamental dominar os conceitos de OAuth 2.0, OIDC e o funcionamento do Keycloak como IdP.

Alternativa A — ✅ Correta ⟵ GABARITO

A alternativa está correta porque descreve com precisão o papel do Keycloak no fluxo OAuth 2.0. O Keycloak, como Identity Provider (IdP), atua como Authorization Server, sendo responsável por autenticar os usuários e emitir access tokens e refresh tokens para as aplicações cliente. Essa é a função central do Keycloak em uma arquitetura de autenticação centralizada, permitindo que os aplicativos do tribunal acessem recursos protegidos de forma segura.

Alternativa B — ❌ Incorreta

A alternativa está incorreta ao afirmar que o Keycloak "apenas suporta OAuth2 para autenticação federada" e que seria necessário um provedor externo para login unificado. O Keycloak é um IdP completo que suporta OAuth 2.0 e OpenID Connect, podendo atuar como authorization server e autenticar usuários diretamente, sem depender de provedores externos. A autenticação federada (com Google, Microsoft, etc.) é um recurso adicional, mas não um requisito para o funcionamento do Keycloak como IdP.

Alternativa C — ❌ Incorreta

A alternativa está incorreta ao afirmar que o Implicit Grant é a opção preferida e mais segura para aplicações web modernas. Na verdade, o Implicit Flow é considerado menos seguro, pois o access token é retornado diretamente na URL de redirecionamento, podendo ser exposto no histórico do navegador e em logs. A recomendação atual é utilizar o Authorization Code Flow com PKCE (Proof Key for Code Exchange) para aplicações web e mobile, que oferece maior segurança.

Alternativa D — ❌ Incorreta

A alternativa está incorreta ao citar fluxos e mecanismos inexistentes: "Authorization Code Lazy (ACL)" e "Proof Authority for Code Exchange (PACE)". Os termos corretos são Authorization Code Flow e PKCE (Proof Key for Code Exchange). O PKCE é uma extensão do Authorization Code Flow que adiciona uma camada de segurança, especialmente para clientes públicos, mas os nomes apresentados na alternativa não existem no protocolo OAuth 2.0.

Alternativa E — ❌ Incorreta

A alternativa está incorreta ao afirmar que o OAuth2, implementado no Keycloak, não suporta refresh tokens. O OAuth 2.0 define o refresh token como um tipo de token que permite obter novos access tokens sem a necessidade de nova autenticação do usuário. O Keycloak, como authorization server, suporta a emissão e o uso de refresh tokens para renovação de sessão. Além disso, a alternativa confunde os papéis: o ID token é uma extensão do OpenID Connect, não do OAuth 2.0 puro.

Gabarito: letra A