Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Version History

« Previous Version 13

Introdução

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.

Roles (papéis)

  • 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.

Utilização

Na imagem acima, podemos visualizar 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;

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;

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; (Utilizado na external API - Privacy Tools)

  • Client Credentials – pode ser utilizado quando a aplicação client é protegida, que são utilizados em integrações de sistemas;

Para confirmar a utilização: Privacidade>>Consentimentos>>API Integração, aba 'Integre com sua aplicação:

client-id e client-secret correspondem ao usuário e senha da aplicação esta é passada como user basic no authorization do endpoint de geração de token juntamente com os parâmetros no body:

  • username = valor de Public Key

  • password = valor de Secret

  • grant_type = valor de scope

Url do endpoint geração de token, exemplo:

URL de homologação: https://demo.privacytools.com.br/external_api_v2/oauth/token

URL de produção: https://dpo.privacytools.com.br/external_api_v2/oauth/token

o campo Curl Token Authorization nos facilita já construindo a string em curl de uma requisição ao endpoint de geração de token:

O campo Authorization nos fornece através de geração automática do token de acesso para a conta company logada, permitindo o teste no swagger instantaneamente como segue na imagem acima.

Para todas as chamadas de todos os  endpoints da external api, basta passar o token no Authorization como na imagem acima além dos parâmetros usuais de cada endpoint para o correto funcionamento.

  • Esta documentação aborda de maneira abrangente e minuciosa o tema em questão. No entanto, com o intuito de fornecer informações detalhadas, fundamentadas e provenientes de diversas fontes para uma compreensão completa e precisa, segue a documentação que apresenta o passo a passo de como utilizar e obter o token. API - Obter token.

  • No labels