OAuth | Como (2 de 2)
Na publicação: OAuth | O que e por que nós vimos que nossas credenciais (por exemplo, usuário e senha) ficam armazenadas num repositório único, no provedor autenticador (Google, Facebook, etc) e ainda assim nosso acesso é liberado às diversas funcionalidades de um determinado site, no nosso exemplo, o Evernote. Como isso acontece? O que é trafegado então?
O padrão trabalha essencialmente com tokens, detalhados mais abaixo, que podem ser obtidos na execução dos fluxos de autenticação ou atribuídos conforme o processo de governança da corporação, pois esse padrão pode ser aplicado externamente, entre sites, ou internamente, entre aplicativos de uma mesma empresa ou corporação:
CLIENT_ID: Token que identifica de forma única o aplicativo que deseja utilizar as APIs. O CLIENT_ID é atribuído pelo processo de governança.
CLIENT_SECRET: Token secreto do aplicativo, utilizado para obtenção do ACCESS_TOKEN e/ou o GRANT_CODE, também é atribuído pelo processo de governança.
GRANT_CODE: Token de autenticação de uso intermediário, concedido para aplicativos de terceiros para obtenção do ACCESS_TOKEN. O GRANT_CODE é criado no processo de autenticação do fluxo Authorization Code.
ACCESS_TOKEN: Token de autenticação, comprova que houve um processo de autenticação do aplicativo e, se for o caso, do usuário do aplicativo. O ACCESS_TOKEN é fornecido como resultado do processo de autenticação.
REFRESH_TOKEN: Token utilizado para obter um novo ACCESS_TOKEN quando o mesmo estiver expirado. O REFRESH_TOKEN é criado juntamente com o ACCESS_TOKEN como resultado do processo de autenticação.
E quais são os fluxos do OAuth?
Client Credentials: Fluxo utilizado por aplicativos confiáveis ou aplicativos de terceiros, onde é necessário que seja feita a autenticação apenas do aplicativo, ou seja, não é necessário autenticar o usuário do aplicativo. Esse fluxo tem como objetivo obter um ACCESS_TOKEN através do uso do CLIENT_ID e CLIENT_SECRET do aplicativo.
Considere o seguinte eccossistema:
Essa será a jornada para obtenção do ACCESS_TOKEN:
Passo 1 - Request ACCESS_TOKEN por debaixo dos panos:
POST /api/oauth/token HTTP/1.1
Host: seu.provedor.autenticador
Content-Type: application/x-www-form-urlencodedgrant_type=client_credentials&client_id=12345valorclientid&client_secret=67890valorclientsecretExemplo:
curl -i -k -H "Content-Type: application/x-www-form-urlencoded" -X POST --data-urlencode "client_id=12345valorclientid" --data-urlencode "client_secret=67890valorclientsecret" --data-urlencode "grant_type=client_credentials" https://seu.provedor.autenticador/api/oauth/token
Passo 2 -Response ACCESS_TOKEN:
Resposta esperada: httpStatus 200
{
"access_token": "um.token.gigante.eh.retornado.aqui",
"token_type": "Bearer",
"expires_in"": 3600,
"refresh_token": "um.token.menor.eh.retornado.aqui",
"scope":"resource.READ"
}
Uma vez que temos o ACCESS_TOKEN podemos requisitar a API/serviços desejado, Passo 4 -Request Resource with ACCESS_TOKEN:
GET /um/resource/qualquer HTTP/1.1
Host: host.servico.desejado
Authorization: Bearer um.token.gigante.eh.retornado.aqui Exemplo:
curl -i -k -H "Content-Type: application/json" -H "Authorization: Bearer um.token.gigante.eh.retornado.aqui"
-X GET http://host.servico.desejado/um/resource/qualquer
Como ainda não tenho experiência nos demais fluxos não contribuirei com exemplos como ocorreu com o fluxo Client_Credentials.
Resource Owner Password Credentials: Fluxo utilizado por aplicativos confiáveis, onde é necessário que seja feita a autenticação do aplicativo e do usuário do aplicativo. Esse fluxo tem como objetivo obter um ACCESS_TOKEN através do uso do CLIENT_ID e CLIENT_SECRET do aplicativo e dos dados de autenticação do usuário (exemplo: login e senha). Por se tratar de um aplicativo confiável, o login e senha do usuário pode ser digitado no próprio aplicativo.
Authorization Code: Fluxo utilizado por aplicativos de terceiros, onde é necessário que seja feita a autenticação do aplicativo e do usuário do aplicativo. Esse fluxo tem como objetivo obter um ACCESS_TOKEN através do uso do CLIENT_ID e CLIENT_SECRET do aplicativo e dos dados de autenticação do usuário (exemplo: login e senha).Por se tratar de um aplicativo de terceiro, o login e senha do usuário não podem ser digitados no aplicativo, portando, a API deve fornecer uma tela de autenticação para que o usuário digite o seu login e senha. Normalmente essa tela de autenticação é exibida através de uma janela popup.
Implicit: Fluxo utilizado por SPA (Single Page Applications) confiáveis ou de terceiros que executam em browsers e não são capazes de armazenar um CLIENT_SECRET, já que ele poderia ser facilmente recuperado do código fonte da página. Esse fluxo tem como objetivo obter um ACCESS_TOKEN através do uso do CLIENT_ID do aplicativo e, se for necessário, dos dados de autenticação do usuário (exemplo: login e senha). O ACCESS_TOKEN é retornado para o aplicativo através de uma URL de Redirecionamento (REDIRECT_URI) do aplicativo, que deve ter sido previamente cadastrada no portal do desenvolvedor. Podemos dizer que a URL de Redirecionamento é o que “autentica” o aplicativo, porém esse é o fluxo menos seguro do oAuth e deve ser utilizado com parcimônia.
Refresh Token: Fluxo utilizado para renovar um processo de autenticação quando o mesmo estiver expirado. Esse fluxo tem como objetivo obter um novo ACCESS_TOKEN através do uso do REFRESH_TOKEN.
Referências:
https://sensedia.com/apis/quando-devo-utilizar-fluxos-do-oauth/
Originally published at http://deviniciative.wordpress.com on July 11, 2019.
