Conteúdo original nessa thread do Twitter

Ei dev,

Quer abafar real no próximo date falando sobre OAuth 2.0? Então cola aí pra gente falar sobre algumas coisas básicas. Assim, você chega ao final do date com o crush na sua e sem necessidade daqueles beijos bons, sensuais e mundanos – credo!

cc @sseraphini

↓

Disclaimer: Não vai ser uma thread que explica toda a complexidade desse protocolo/framework que é encardido e cheio de nuances. Mas fica aí se vc quiser entender algumas coisas básicas.

Fiz questão de escrever OAuth 2.0 pq é a versão atual e que deveria ser usada. Existe o OAuth 1.0 que está obsoleto.

De toda forma, sempre que eu escrever apenas OAuth, entenda que seja a versão atual – a 2.0 –, ok?

OAuth é sobre AUTORIZAÇÃO e não autenticação! Claro que é necessário se autenticar para poder autorizar, mas esse framework (a RFC chama o OAuth de framework) nem entra muito nesses detalhes. Só fala que tem que ser seguro, adequado, etc. De boa? Ah, e é um framework para o HTTP!

No OAuth existem quatro papéis (roles) e vou falar bem rapidamente sobre cada um. Na prática você não precisa entender profundamente eles, a não ser que esteja implementando o protocolo (ah, eu chamo o OAuth de protocolo, mas acho que o certo mesmo é framework).

Resource Owner:

É o "dono" do recurso. Pode ser uma pessoa ou um serviço. Por exemplo, você é o dono das suas coisas no Facebook (fotos, bio, etc.) e é você quem permite ou não acesso a elas (na teoria, né? rsrs).

Resource Server:

É onde ficam os recursos protegidos (suas fotos do Instagram, por exemplo). Esse server precisa ser capaz de lidar com tokens de acesso (access tokens) pra fornecer, negar, etc. os acessos aos recursos protegidos.

Client:

É basicamente a aplicação que quer acessar os recursos protegidos. (Essa parte agora é importante, se liga.) A aplicação acessa os recursos EM NOME do Resource Owner (do dono do recurso). Sabe aquele app que vc se loga usando o Twitter? Então, ele seria um Client, blz?

Authorization Server:

É a entidade (server) que emite os tokens de acesso. É o guardinha do rolê. Sabe aqueles requests que vc faz pra conseguir o access token? Então, esse é o Authorization Server. É aqui que o OAuth meio que "tira o corpo" e não define como é a autenticação.

Agora vou DESTRETIZAR um pouco essas coisa de roles e servers. Apesar de haver dois Servers (Resource e Authorization) NADA impede que eles, na prática, estejam hospedados no mesmo servidor. Isso é importante! (Essa informação equivale a pegar na mão pela primeira vez no date.)

--

Claro, nada impede que eles estejam hospedados em locais diferentes também. Só quis enfatizar que o OAuth não determina isso.

Agora queria falar de outro negócio que vejo muita gente não saber. Manja o famoso access token em formato JWT? Aquele troço que vc mete no header Authorization, decoda e tem um monte de coisas lá? Então, lá PODE ter um atributo que se chama "sub".

Esse "sub" significa subject. É esse atributo que identifica o dono do recurso. Por exemplo, talvez o "sub" dum access token pudesse ser o CPF ou o login de uma pessoa. (Pega essa dica agora.) Quando esse atributo existe, significa que o Client está REPRESENTANDO esse subject!

Então todos esses apps que usamos e fazemos em que pedimos pro usuário autorizar numa rede social, por exemplo, o access token vai ter esse "sub" identificando o usuário. Confia!

Isso nos leva a falar de outra parada. OAuth também pode ser usado pra autorizar o acesso de recursos que NÃO representam uma pessoa/usuário. Esse tipo de autorização é chamada de Machine to Machine (M2M). Os access tokens NÃO vão ter o atributo "sub" nesses casos.

Saber isso pode te facilitar pra quando você quiser permitir apenas acessos de Clients que estejam representando um usuário. ( if "sub" not in JWT, return HTTP 403 "fuck off, bitch!" )

(Essa info é mais gostosa do que beijar a parte de dentro do braço do crush. Confia.)

Já tô cansado de escrever essa thread e você também tá de ler que eu sei, mas aguenta só mais um pouco que vou falar da última coisa que acho básica: os grant types! Não vou descrever cada um pq olha... tem uns aí que pelo amor, viu? Muito complicado.

Os grant types nada mais são do que os fluxos para a obtenção dos access tokens! Algumas vezes talvez vc os veja sendo referidos como flows ou authorization flows – é tudo a mesma coisa.

Mini cheat sheet dos grant types:

Cliente Credentials: usado em autorizações M2M pra quando não houver usuários envolvidos ("como faço pro meu backend chamar o seu?"). Lembre-se, nesse flow, o access token não terá o "sub"!

Authorization Code: muito usado em apps que pedem autorização pra acesso nas redes sociais. Vc loga e autoriza NO SITE da rede social e depois é redirecionado pro app/site Client. Vem um código, o Cliente troca o código blah blah blah... Complexo esse fluxo e nunca vou decorar.

Device Code: pra quando não tem um browser no fluxo e/ou bastante restrições. Se um dia vc quiser fazer um console com restrições pra usar browsers que obtêm access tokens, é esse grant type que deveria usar.

Refresh Token: pra vc usar esse fluxo, vc tem que primeiro ter um access token. Aí o access token expira e vc troca por um novo access token usando o refresh token. Esse fluxo é pra não precisar da interação do usuário pra obter novos access tokens.

Password: Esse fluxo é obsoleto e não recomendado. Pq? Pq vc insere as suas credenciais no Client! Imagina um app que pede pra vc logar com o Facebook, mas pede que vc insira suas credenciais NESSE app? Zuado, né? A não ser que o Client seja confiável, não use esse flow!

Existem outros flows, mas esses são os que mais vejo sendo usados.

Ah, lembrei duma treta que já vi muito! Clients que, pra cada requisição, chamam o endpoint pra obter o access token! Sério, cada vez que alguém codifica isso, morre um filhotinho de foca. Não seja essa pessoa – usa um cache, sei lá... colabora com o Authorization Server! 🙄

Se você não conquistar seu crush com esse papo de OAuth, sinceramente não sei se vc tem mais jeito, sabe? Sinto muito.

Ah, preciso nem falar, né? Se você leu até aqui, me dá um abraço aqui ó 🤗

Obrigado demais pela moral! 💕