OAuth: uma rápida visão geral

OAuth é, com folga, o protocolo de autorização mais utilizado em aplicações web. Se você faz parte desse mundo de integrações, é praticamente impossível não ter lidado com ele. É por isso que decidi criar este conteúdo e compartilhar parte da imersão que fiz ao longo dos últimos meses.

O que é OAuth?

É um protocolo de autorização no qual, de forma simples e padronizada, é possível que o client (aplicações) acesse um recurso protegido em nome do usuário. É um framework de segurança que descreve como conceder acesso aos dados dos usuários em uma aplicação, através do protocolo HTTP.

Quer saber mais sobre segurança de APIs? Clique aqui e baixe este conteúdo especial!

Roles

São os papéis que cada entidade terá durante um fluxo de autorização. Os principais são:

Resource Owner: entidade capaz de autorizar acesso a um recurso protegido. Se for uma pessoa, pode ser chamado de usuário final.

Resource Server: servidor que hospeda os recursos protegidos - uma API, por exemplo.

Authorization Server: ou OAuth Server, é o servidor que fornece acesso a um recurso protegido em nome do usuário. É onde são validados os fluxos e gerados os tokens.

Client: aplicação que deseja acessar os recursos privados do resource owner.

Grant Types

São os fluxos de autorização utilizados para autorizar um client a acessar recursos privados do resource server em nome do resource owner. No OAuth 2.0, são contemplados 4 grant types:

• Client Credentials
• Authorization Code
• Implicit Flow
• Password Grant

Bearer Tokens

É um tipo de token de acesso. É uma string opaca, ou seja, sem informações autocontidas. Ele pode ser passado via header em uma requisição HTTP (forma mais comum). Caso seja utilizado método POST, pode ser passado no body da requisição ou, caso seja utilizado método GET, na query string. Ex token: c0ce7f40-e12b-393e-bb7c-5ad1fc3c9841.

JWT

JSON Web Tokens, além de serem um tipo de token de acesso, são também uma string. Contudo, se diferenciam do bearer token, pois contêm informações autocontidas e devem ser assinados e criptografados. É um token transparente, estruturado em 3 partes: header, no qual é informado o algoritmo de criptografia utilizado e o tipo do token; payload, que é o dado propriamente dito, onde são passadas informações relevantes (claims) e nunca sensíveis; e a calda, onde o mesmo é verificado e assinado. Vejam o exemplo abaixo:

OAuth 2.1

O OAuth 2.0 é de 2012 (RFC 6749). De lá pra cá, muita coisa mudou - popularização do javascript, diversos tipos de ataque, injeções e formas de interceptação e muito mais. Sendo assim, algumas mudanças foram necessárias e é por isso que existe o projeto OAuth 2.1 (RFC pendente até o momento dessa publicação). As principais mudanças são:

• Fluxo Authorization Code com PKCE(RFC 7636)
• Descontinuação dos fluxos Implicit e Password
• Não passar o token na query string (apenas no header ou no body de um POST)

‍

Os grant types do OAuth 2.1 são Client Credentials e Authorization Code + PKCE. E o token (seja opaco ou transparente) passa-lo apenas via header ou no body de uma requisição POST:

No próximo post, veremos como funciona o fluxo Client Credentials e Authorization Code + PKCE, qual fluxo é recomendado para determinado tipo de aplicação e mais.  

Obrigado pela leitura e nos encontramos em breve!

Quer saber como a Sensedia ajuda seus clientes a ganhar mais agilidade e eficiência? Clique aqui e confira nossos cases!