No protocolo OAuth2, a emissão de tokens de acesso ao cliente após autenticação e autorização é responsabilidade do
- A)resource credential.
Errada: resource credential não é um papel definido no OAuth2 para emitir token de acesso.
- B)resource owner.
Errada: o resource owner apenas concede autorização, mas não gera token.
- C)resource server.
Errada: o resource server protege o recurso e valida o token, não o emite.
- D)authorization server.
Certa: o authorization server é quem autentica, processa a autorização e emite o token de acesso.
- E)client registration.
Errada: client registration trata do cadastro do cliente, não da emissão do token.
Gabarito: D
No OAuth2, pense em uma divisão de tarefas bem organizada: o cliente pede acesso, o usuário dono do recurso autoriza, e alguém confiável entrega o token. Quem faz essa emissão do token de acesso, depois que a autenticação e a autorização foram confirmadas, é o authorization server. Ele é a peça que valida as permissões e gera o token que o cliente vai usar nas chamadas futuras. O resource owner é o dono do recurso, isto é, normalmente o usuário. Ele não emite token, ele apenas concede ou nega consentimento. O resource server, por sua vez, é quem guarda o recurso protegido e verifica se o token apresentado é válido. Já o client é o aplicativo que quer acesso, mas também não é quem emite token. Essa lógica aparece na própria arquitetura do OAuth2, consolidada na RFC 6749, que separa claramente as funções para evitar confusão. Em prova, a banca adora trocar os papéis: quem autentica e autoriza não é necessariamente quem guarda o dado, e quem guarda o dado não é quem fabrica o token. Aqui, portanto, a responsabilidade pela emissão do token de acesso é do authorization server.