O OAuth2 é um protocolo padrão para autorização. Permite que aplicativos como Web App, Mobile e Desktop obtenham acesso limitado às informações de usuários através do protocolo HTTP.

Este artigo dará um overview sobre o OAuth2. Vai descrever suas principais funcionalidades. Pode ser utilizado como guia para aqueles que não estão familiarizados com o protocolo.

Se você possui dúvidas sobre as diferenças entre JWT, Bearer e OAuth2. Não entende bem essa sopa de letrinhas, leia este artigo primeiramente: Segurança - JWT x Cookies x OAuth2 x Bearer.

Roles (Papéis)

O OAuth2 define 4 roles.

  • Resource Owner - É a pessoa (entidade) que concede o acesso aos seus dados. Literalmente o Dono do Recurso. É como o OAuth2 classifica o usuário.

  • Resource Server - A Api. Exposta na interne e protege os dados. Para conseguir acesso ao seu conteúdo é necessário um token emitido pelo Authorization Server.

  • Authorization Server - Responsável autenticar o usuário e emitir tokens de acesso. Possui as informações dos Resource Owner (Usuários). Autentica e interage com o usuário após a identificação do client.

  • Client - É a aplicação que interage com o Resource Owner. No caso de uma App Web, seria a aplicação do Browser.

Fluxo do protocolo

Este é fluxo padrão do protocolo. Demonstra de forma simplificada os papéis dos envolvidos.

roles-2

Explicando o fluxo de uma maneira prática.

  • (A) O Usuário acessa um client. Para ter acesso ao conteúdo protegido da api (Resource Server) o client (A) Solicita Autorização(implicity) ao Resource Owner.
  • (B) A Autorização é Concedida pelo usuário (Resource Owner) ao, por exemplo, clicar no botão Login.

client-request-grant

  • (C) O client solicita um token de acesso ao Authorization Server através da autenticação de sua própria identidade.
  • (D) O Usuário (Resource Owner) confirma sua identidade através do seu usuário e senha ou através de um terceiro (Facebook, Google). Se tudo ocorrer bem um Access Token será criado e devolvido para o client gerenciar.

access-grant
callback

  • (E) Por fim o client informa o Access Token ao Resorce Server.
  • (F) O Resource Server faz validação e retorna o Conteúdo Protegido.

O fluxo pode diferenciar, dependendo da configuração da aplicação, como por exemplo no Password flow, onde o cliente não é redirecionado para o Authorization Server.

1 - Authorization Server

É o Single Sign On (SSO) em sí. Centraliza as credenciais de acesso dos usuários. Faz a autenticação do usuário. Responsáver também por:

  • Identificar e autenticar Resource Server, Clients e Usuários.
  • Gerenciar as claims (Permissões dos usuários).
  • Emitir Access Token.

2 - Clients

Entenda como Client uma aplicação que roda na máquina do usuario. O OAuth define dois tipos de aplicação.

  1. confidential - clients que são capazes de manter a confidencialidade de suas credenciais. Por exemplo, cenários de integração, onde um serviço externo da organização desenvolve um serviço que irá consumir a WebApi da empresa.
  2. public - clients incapazes de manter a confidencialidade de suas ceredenciais. Uma WebApp, por exemplo, ela está exposta e qualquer usuário consegue saber suas credenciais.

O OAuth2 define fluxos, seguros, especifico para cada um dos casos. O server OAuth2 deve permitir o registro de Apis. Para isso o cadastro deve permitir:

  • Especificar o tipo do client (public ou confidential)
  • Informar ao URL's de redirecionamento.
  • Salvar informações como Website, Logo e etc.

Redirect URI

Para prevenir ataques o server só irá redirecionar o usuário para a URL cadastrada. A URL deve estar protegida por um HTTPS, evitando ataques man-in-the-middle.

Client ID e Secret

Ao registrar um client, o server deve disponibilzar um Client ID e uma Secret. Se o client for público, então o Secret não é criado.

Autorização

O OAuth2 define 4 tipos de fluxos de autorização. O fluxo vai depender do client. Como irá solicitar o Access Token e o tipo de client.

  • Authorization Code - O código de autorização é obtido usando um Authorization Server como intermediário entre o client e o usuário. O client redireciona o usuário para um servidor de autorização.

  • Resource Owner Password Credentials - Mais conhecido como Usuário e senha. Utilizado quando o Client solicita o usuário e senha diretamente.

  • Implicit - O implicit é um fluxo de autorização simplificado. Otimizado para clients web. Ao emitir um Access Token, o Authorization Server não autentica o cliente. Em alguns casos, a identidade do client pode ser verificada por meio do URL de redirecionamento.

  • Client Credentials - Pode ser usado quando a aplicação client é protegida. Um serviço que consulta uma api.

A tabela a seguir contém um guia de quando utilizar cada um dos fluxos.

Tipo de client Fluxo de autorização
SPA's, MVC Implicit
Aplicações não confiaveis (Apps de terceiros) Authorization Code
Aplicações confiáveis (apps internas da empresa) Authorization Code ou Resource Owner Password Credentials
Integrações de sistemas (apps background) Client credentials

Access token

São credenciais usadas para acessar recursos protegidos. É uma string que representa uma autorização emitida para o client. Os tokens possuem informações que o usuário concedeu ao Authorization Server, como nome, e-mail e endereço. Possui os dados da sessão como o tempo de duração do acesso.

A natureza do token permite camadas de abstração, permitindo informações adicionais. Por exemplo os dados do usuário, endereço. Mais comumente é utilizado para guardar as claims de autorização.

Os tokens são abrangentes, podem ter diferentes formatos e estruturas. São utilizados de muitas maneiros, alguns criptografados. Ele é gerado com base nos requisitos de segurança da empresa.

Devido essa abrangencia, possui uma RFC somente para ele, RFC6750.

Referencias