Oauth2 é um padrão de Autenticação Aberta, este padrão permite que você possa logar e disponibilizar informações de contas suas através de aplicativos terceiros sejam eles internos ou externos.

As imagens acima estão inteiramente ligadas com o OAuth2, a partir delas começa um fluxo de autenticação que chamamos de Authorization Code mas isso fica mais pra frente neste artigo.

o padrão OAuth2 pode ser divido em quatro partes, são elas...

• Resource Owner
• Resource Server
• Client
• Authentication Server

Resource Owner

É o dono do recurso, basicamente o modo em que o oauth2 chama o usuário, é ele quem autoriza a utilização dos seus dados por uma aplicação terceira e é dele que o Authentication Server gerencia e autentica as informações.

Resource Server

É o servidor que obtém o recurso e esta exposto na internet, é a informação do usuário vinculada nele que será passada ao client ( aplicação que faz a requisição ) e precisa proteger seus recursos com um token, normalmente é o tipo de client confidential que possui um vínculo direto com a Authentication Server.

Client

Aplicação requisitante dos dados do cliente, ela quem faz a requisição e utiliza os tokens retornados para fazer pedidos ao Resource Server.

Authentication Server

Servidor que contém as credenciais do client, do resource server e principalmente do usuário a ser autenticado, este servidor faz a verificação e autenticação dos requisitantes e emite os tokens de acesso que possuem os dados de acesso do usuário.

Fluxo Durante o Processo de Autenticação

O processo muda dependendo do tipo de aplicações e vínculos Para utilizar os dados de outras aplicações grandes como o Google ou Facebook, normalmente é preciso preencher um formulário que fornecerá uma client-id passando informações sobre sua aplicação em campos como URL da aplicação e URI de Redirecionamento que redireciona o usuário após a autenticação ( isso no caso de uma aplicação terceira que irá usar os serviços ).

Responsabilidades

( Authentication Server e Client )

Authentication Server

É responsável pelo SSO ( Single Sign On ) o que significa que ele centraliza Credenciais de acesso do usuário, ele identifica e autentica o requisitante ( client ), Resource Server e Usuário, além de ser responsável por gerenciar as claims e emite o Access Token.

Client

É divido em 2 tipos de aplicação

Confidential ( Serviços Back-end como Java ou .NET )

Aplicações que são capazes de manter em segredos suas credenciais, normalmente visto em um cenário de integração onde um serviço externo da organização desenvolve um serviço que irá consumir a web API da empresa. Neste caso é gerado um Client ID e um Secret.

Public ( Serviços Front-end ou apps Mobile )

Clientes Incapazes de manter a confidencialidade de suas credenciais, uma web app por exemplo está exposta a qualquer usuário que conseguiriam saber suas credencias. sendo assim utilizamos uma abordagem diferente utilizando apenas o Client-ID.

Fluxos de Autorização

• Implicit
• Authorization Code
• Resource Owner Password Credentials
• Client Credentials

Implicit

( Muito utilizado em SPA ou MVC )

É 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 caso o URL do cliente pode ser vista na URI e redirect.

Abaixo vemos o fluxo do implicit

Authorization Code

( Muito usando em aplicações de terceiros )

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.

Abaixo o fluxo do Authorization Code

Resource Owner Password Credentials

( utilizado em aplicações confiáveis como aplicações internas da própria empresa )

Mais conhecido como usuário e senha, é utilizado quando o client solicita o usuário e senha diretamente.

Abaixo o fluxo do Resource Owner Password Credentials

Client Credentials

Pode ser usado quando a aplicação client é protegida, um serviço que consulta APIs que são utilizadas em integrações de sistemas.

Abaixo o fluxo do Client Credentials