OAuth: uma rápida visão geral - Parte II

Na primeira parte deste conteúdo, foi apresentado o que é OAuth, para que serve, roles, grant types, bearer tokens e JWT, e um pouco do projeto OAuth 2.1. Nessa continuação, vou demonstrar como funcionam os fluxos de autorização (grant types).

Client Credentials

Client Credentials é utilizado quando clients (aplicações) solicitam um token para acessar seus próprios recursos em seu nome, não em nome do usuário. Esses clients geralmente são aplicações machine-to-machine (M2M), como CLIs, daemons ou serviços rodando no backend. Por isso, esse fluxo deve ser utilizado apenas para clients confiáveis. Veja abaixo como funciona.

1. Aplicação (m2m app) envia request (/oauth/token) para OAuth server com Client ID + Client Secret
2. OAuth Server valida Client ID + Client Secret
3. OAuth Server responde com o token de acesso
4. Aplicação usa o token para chamar a API
5. API responde com dado requisitado

Authorization Code + PKCE

Este fluxo é utilizado para, através de um código de autorização, obter um token de acesso. Neste cenário, estamos falando de aplicações confiáveis e aplicações públicas, sejam elas web, mobile ou nativas.  

Diferente do Client Credentials, neste caso o resource owner é um usuário final, por isso, a aplicação precisa abrir o browser para iniciar o fluxo. Como envolve aplicações públicas, são necessárias algumas medidas a mais de segurança, por isso, temos o Proof Key for Code Exchange, ou PKCE (RFC 7636). Ele é uma extensão do fluxo Authorization Code que previne ataques de injeção e CSRF, criando um "segredo" a cada requisição de autorização. Juntamente com esse segredo e o código de autorização (authorization code), solicita um token de acesso. Veja na imagem abaixo.

‍

1. Usuário clica em "Login" na aplicação.
2. Aplicação cria um code_verifier e, a partir dele, gera o code_challenge.
3. Aplicação envia request (/authorize) para OAuth Server usando o code_challenge.
4. OAuth Server redireciona o usuário para logar e solicita autorização.
5. Usuário autentica/consente.
6. OAuth Server guarda o code_challange e redireciona o usuário para aplicação com um authorization code.
7. Aplicação envia request (/oauth/token) com authorization code + code_verifier para o OAuth Server.
8. OAuth Server valida code_challenge (enviado no passo 3) e code_verifier (enviado no passo 7).
9. OAuth Server responde com o token de acesso.
10. Aplicação usa o token para chamar a API.
11. API responde com dado requisitado.

A recomendação do protocolo é que, para aplicações M2M, utilize Client Credentials e, para outros tipos de aplicações, Authorization Code + PKCE. Como expliquei na parte I, a ideia desses 2 artigos é dar um rápido overview sobre OAuth. Espero que tenha conseguido. Agradeço mais uma vez quem leu até aqui e até a próxima!

Gosta de conteúdo técnico? Confira nossos materiais especiais, para você aprofundar seu conhecimento!