O que é OAuth?
OAuth 2.0 é um framework de autorização que permite a uma aplicação obter acesso limitado a recursos protegidos, em nome de um usuário ou da própria aplicação.
Quais são os papéis no OAuth?
O cliente é a aplicação que pede acesso. O servidor de autorização verifica as condições da concessão e emite tokens. O servidor de recursos é a API que recebe a chamada. Nos fluxos delegados, o titular do recurso participa da autorização conforme a política do serviço. A IETF RFC 6749 — OAuth 2.0 define esses papéis e os tipos de concessão.
OAuth é um protocolo de autenticação?
OAuth trata de autorização. Para uma aplicação verificar o login de uma pessoa, OpenID Foundation — OpenID Connect Core 1.0 acrescenta uma camada de identidade sobre OAuth 2.0. O ID token se destina ao cliente que solicitou a autenticação; o access token se destina ao recurso protegido. Um não deve ser usado como substituto do outro.
Como escolher o fluxo?
Em fluxos interativos com redirecionamento, use Authorization Code com PKCE e uma implementação atualizada. Client Credentials atende a clientes confidenciais que atuam em nome próprio, sem representar o login de uma pessoa. Essa escolha depende do tipo de cliente e das permissões necessárias.
A IETF RFC 9700 — práticas atuais de segurança OAuth atualiza as recomendações de segurança: o fluxo que entrega a senha do usuário ao cliente, Resource Owner Password Credentials, não deve ser utilizado. A emissão de tokens de acesso diretamente na resposta de autorização, como no Implicit Grant, também deve ser evitada.
Exemplo: integração com calendário
Uma ferramenta precisa consultar a agenda, mas não enviar mensagens. O projeto deve solicitar somente as permissões de leitura necessárias e confirmar a API de destino. O exemplo é ilustrativo: os nomes dos escopos e a forma de consentimento variam entre provedores.
Quais cuidados verificar?
- Limitar escopos, recursos de destino e duração das autorizações.
- Conferir redirecionamentos cadastrados e as proteções contra falsificação de solicitações.
- Proteger access tokens e refresh tokens contra exposição em logs e URLs.
- Prever revogação de consentimento e encerramento de integrações que deixaram de ser usadas.
OAuth não exige que todo access token seja um JWT. O formato e a validação devem seguir o contrato do servidor de autorização e da API.

