OAuth 2.0 em português claro — parte II
O framework OAuth 2.0, descrito na RFC 6749, é um padrão de segurança de aplicações largamente adotado em todo o mundo, dado sua interoperabilidade, facilidade de implementação, suporte as mais diversas plataformas, entre outros fatores.
Nesta parte II vamos exercitar um caso de uso, ressaltando as roles (papéis) descritos na especificação OAuth 2.0.
Convido você a ler a parte I desta série, onde passamos brevemente pela história do surgimento do OAuth, os problemas que o framework direciona e exercitamos 2 casos de uso para reforçar o entendimento da dinâmica de Identificação, Autenticação e Autorização.
Aproveite a leitura!
O OAuth 2.0, descrito na RFC 6749, possui quatro Roles (papéis).
Resource Owner
Literalmente o dono do recurso, podendo ser uma aplicação ou uma pessoa. O dono do recurso é quem autoriza o acesso ao recurso protegido.
Resource Server
É o servidor onde é hospedado os recursos protegidos, tendo a capacidade de aceitar ou negar uma requisição dado a verificação de um access token (chave de acesso).
Client
É a aplicação de onde parte a requisição para um recurso protegido, personificando ou representando o Resource Owner. O termo client na especificação não se refere a nenhuma característica de implementação, ou seja, a aplicação pode estar executando em um servidor, desktop, device mobile ou outros tipos de plataformas.
Todo Client é previamente registrado no Authorization Server, recebendo uma identificação denominada Client Id e um segredo denominado Client Secret quando for um Confidential Client.
Publics Clients: são as aplicações que executam no client-side (lado cliente), exemplo um app mobile. Publics Clients não possuem Client Secret, pois dado que estão rodando no lado cliente, não tem como guardar um segredo de forma segura.
Confidential Clients: são as aplicações que executam no server-side (lado servidor).
Authorization Server
Literalmente o servidor de autorização, tem a responsabilidade de emitir os access tokens (chaves de acesso) para acessar um recurso protegido do Resource Server, a partir de um Client, mediante a autorização do Resource Owner após a autenticação do mesmo.
A descrição das roles do framework do OAuth não são claras e podendo gerar mais dúvidas do que esclarecimentos.
Vamos exercitar um caso de uso, onde cada role é representada.
Alice abre o aplicativo do Medium, a primeira tela é o splash com o logo do Medium e logo em seguida é carregada a tela com as opções para acessar a plataforma.
Ao clicar no botão “Sign up with Google”, o app Medium faz uma requisição ao Google Accounts, pedindo uma chave de acesso para consumir um recurso protegido.
Neste passo o app Medium é o Client e o Google Accounts é o Authorization Server.
Quando o Authorization Server recebe o pedido de autorização para acessar um recurso protegido, submete o passo de Identificação e Autenticação.
Neste passo, a Resource Owner Alice se identifica, se autentica e consente que o Client app Medium pode acessar os recursos protegidos em seu nome. Dado o consentimento do Resource Owner, o Authorization Server emite um access token (chave de acesso) para o Client com o poder de acessar os recursos protegidos.
Em posse do access token (chave de acesso), o Client solicita os dados para carregar a home.
Neste último passo, após ter se identificado e se autenticado, a Resource Owner Alice consentiu que o Client app Medium pode lhe representar acessando os seus dados protegidos, então o Authorization Server do Google Accounts emitiu um access token (chave de acesso). Em posse do access token (chave de acesso) o Client app Medium pode acessar os serviços do Resource Server Medium solicitando o perfil da Resource Owner Alice, para carregar a home com as suas preferências de leitura.
Nesta parte aprendemos sobre as Roles (papéis) do framework OAuth 2.0.
Continue a leitura na parte III desta série, para conhecer o passo o passo das principais jornadas do OAuth 2.0.