O analista Kléber desenvolveu o web service JusRest, que é protegido por autenticação OAuth2 através do client JusClient, registrado no servidor Keycloak do TJRN. Sendo o JusRest um web service, o administrador do Keycloak desabilitou os fluxos de autenticação OAuth2 para o JusClient. Dessa forma, para consumir o JusRest, o usuário deve fornecer um token já emitido. Para simplificar a integração com o Keycloak, Kléber utilizou no JusRest um adaptador de client do Keycloak. A fim de refletir a configuração do JusClient, Kléber ativou no adaptador a opção que desabilita a tentativa de autenticação do usuário, esperando que seja fornecido um token preexistente. Logo, Kléber ativou no adaptador Keycloak do JusRest a opção:
- A)bearer-only;
Certa: bearer-only faz o adaptador aceitar apenas token bearer já emitido, sem tentar autenticar o usuário.
- B)expose-token;
Errada: expose-token serve para disponibilizar o token à aplicação, mas não desabilita o fluxo de autenticação.
- C)enable-basic-auth;
Errada: enable-basic-auth habilita autenticação básica HTTP, que não tem a ver com aceitar token preexistente.
- D)verify-token-audience;
Errada: verify-token-audience apenas valida a audiência do token, não impede o adaptador de tentar login.
- E)disable-trust-manager.
Errada: disable-trust-manager desativa a verificação de confiança do certificado TLS, não o fluxo de autenticação.
Gabarito: A
Quando um web service usa Keycloak, voce pode configurar o adaptador do client para definir como ele vai lidar com a autenticação. Neste caso, a ideia era simples: o serviço não deveria tentar fazer login do usuário, porque o token já viria pronto, emitido antes. Ou seja, nada de abrir conversa nova com o servidor de identidade: o sistema só aceita o token apresentado e segue a vida. No adaptador do Keycloak, a opção usada para isso é a modalidade bearer-only. Ela indica que a aplicação não vai iniciar fluxo de autenticação nem redirecionar o usuário para login. O serviço apenas recebe e valida um token bearer já existente, o que combina perfeitamente com web services protegidos por OAuth2 que consomem chamadas autenticadas. As outras opções não servem para esse objetivo. Uma cuida de expor token, outra trata de autenticação básica, outra de audiência do token, e outra de confiança no certificado TLS. Nenhuma delas desliga a tentativa de autenticar o usuário. Por isso, o gabarito correto é a alternativa A. Em termos doutrinarios, isso conversa com a lógica de resource server em OAuth2: a aplicação não pede autorização ao usuário, apenas valida a credencial de acesso apresentada na requisição. É o cenário clássico de consumo de API com token previamente emitido.