O que é OAuth 2?

OAuth 2 é um protocolo de autorização que permite que uma aplicação se autentique em outra. Para que isso aconteça, uma aplicação pede permissão de acesso para um usuário, sem que para isso ela tenha acesso a alguma senha dele. O usuário pode conceder ou não o acesso à aplicação. Depois da permissão ser aceita, caso o usuário precise alterar a senha de acesso, a permissão continuará válida para a aplicação e, caso necessário, a permissão dada à aplicação pode ser revogada a qualquer momento também.

Provavelmente você já clicou em algum botão escrito “Logar com sua conta do Google” ou “Logar com sua conta do Facebook” quando você está em alguma outra aplicação, para evitar de ter que fazer na mão algum cadastro. Neste caso, você está dando a autorização de uma aplicação terceira a usar os recursos da sua aplicação, neste caso o Google ou o Facebook. Essas aplicações têm acesso limitado às informações de usuários através do protocolo HTTP. OAuth 2 é utilizado nos mais diversos tipos de autenticação, como em telas de login e na autenticação de APIs (Application Programming Interface).

Curso Zend Expressive - Microframework PHP

Conhecer o curso

Roles (papéis)

OAuth 2 foi construído em cima de 4 papéis, sendo:

• Resource Owner - pessoa ou entidade que concede o acesso aos seus dados. Também chamado de dono do recurso.
• Client - é a aplicação que interage com o Resource Owner, como por exemplo o browser, falando no caso de uma aplicação web.
• Resource Server - a API que está exposta na internet e precisa de proteção dos dados. Para conseguir acesso ao seu conteúdo é necessário um token que é emitido pelo authorization server.
• Authorization Server - responsável por autenticar o usuário e emitir os tokens de acesso. É ele que possui as informações do resource owner (o usuário), autentica e interage com o usuário após a identificação do client.

Como funciona?

Na imagem acima, podemos ver como geralmente funciona o fluxo de autorização.

1. Solicitação de autorização Nessa primeira etapa o cliente (aplicação) solicita a autorização para acessar os recursos do servidor do usuário

2. Concessão de autorização Se o usuário autorizar a solicitação, a aplicação recebe uma concessão de autorização.

3. Concessão de autorização O cliente solicita um token de acesso ao servidor de autorização (API) através da autenticação da própria identidade e da concessão de autorização.

4. Token de acesso Se a identidade da aplicação está autenticada e a concessão de autorização for válida, o servidor de autorização (API) emite um token de acesso para a aplicação. O cliente já vai ter um token de acesso para gerenciar e a autorização nessa etapa já está completa.

5. Token de acesso Quando o cliente precisar solicitar um recurso ao servidor de recursos, basta apresentar o token de acesso.

6. Recurso protegido O servidor de recursos fornece o recurso para o cliente, caso o token de acesso dele for válido.

   O servidor de autorização é responsável pelo SSO (Single Sign On), que centraliza as credenciais dos acessos dos usuários e faz a autenticação, gerencia as permissões dos usuários e emite os tokens de acesso.

O client (aplicação que roda na máquina do usuário) é definido através de dois tipos de aplicação:

• Confidential - clients que são capazes de manter a confidencialidade das suas credenciais
• Public - clients que são incapazes de manter a confidencialidade das suas credenciais

Continuando com os fluxos de autorização, existem 4 formas de se trabalhar com essa integração:

• Implicit - é um fluxo de autorização simplificado, otimizado para clients web. Ao emitir um token de acesso, o authorization server não autentica o cliente. É muito utilizado em SPAs e aplicações MVC.
• Authorization Code - é obtido usando um authorization server como intermediário entre o client e o usuário. O cliente redireciona o usuário para um servidor de autorização. Esse tipo de client é utilizado em aplicações de terceiros, ou seja, não confiáveis.
• Resource Owner Password Credentials - utilizado quando o client solicita o usuário e senha diretamente, esse já utilizado em aplicações chamadas de confiáveis, como aplicações da própria empresa.
• Client Credentials - pode ser utilizado quando a aplicação client é protegida, que são utilizados em integrações de sistemas.