Alternativa C - Cliente, Servidor Web ou API, Servidor de Autorização, Tokens
O protocolo OAuth 2.0 é um padrão de autorização que permite aplicações acessarem recursos protegidos sem expor credenciais diretas do usuário (como senhas) ao recurso final. Para compreender quais elementos compõem esse fluxo, precisamos analisar os atores principais e o mecanismo de segurança utilizado.
Análise dos Componentes
No contexto do OAuth 2.0, existem quatro papéis fundamentais definidos pela especificação RFC 6749:
- Cliente: A aplicação que deseja acessar um recurso em nome do usuário.
- Proprietário do Recurso (Usuário): O usuário que autoriza o acesso.
- Servidor de Autorização: É quem autentica o cliente e emite os tokens de acesso.
- Servidor de Recursos (Servidor Web ou API): Onde os dados residem e valida os tokens recebidos para permitir o acesso.
A alternativa C resume corretamente essa arquitetura:
| Elemento | Função no OAuth 2.0 |
|---|
| Cliente | Aplicações que solicitam acesso aos dados. |
| Servidor Web ou API | Representa o Servidor de Recursos que protege os dados. |
| Servidor de Autorização | Responsável por emitir e validar os certificados de acesso. |
| Tokens | Credenciais temporárias usadas para autenticar requisições (ex: Access Token). |
Por que as outras alternativas estão incorretas?
- A: Foca em Senha e Cookies. No OAuth 2.0, a senha do usuário nunca é enviada para o Servidor de Recursos (API); ela é usada apenas entre o Usuário e o Servidor de Autorização.
- B: Menciona Servidor Criptográfico, que não é um componente padrão da definição de papéis do OAuth.
- D e E: Focam excessivamente em Chaves Públicas/Privadas (usadas em fluxos específicos como JWT ou PKCE, mas não representam o conjunto geral de elementos de controle de acesso básico). Além disso, omitindo o Servidor de Autorização ou Tokens explicitamente, não descrevem o mecanismo completo.
Em resumo, o coração do OAuth 2.0 reside na interação entre o Cliente, o Servidor de Autorização e o Servidor de Recursos, mediada pelo uso de Tokens.