Alguns carros de luxo vem com uma chave extra chamada "valet key".

Essa chave pode ser utilizada quando queremos que um manobrista estacione o carro.

Ao utilizar essa chave para ligar o carro, o manobrista não será capaz de dirigir o carro por mais de 2 km.

Independente da restrição que essa chave especial impõe a seus utilizadores, a ideia é clara: você dá a alguém acesso limitado ao seu carro utilizando uma chave especial e quando quiser acesso ilimitado ao carro, utiliza a chave normal.

Análogo a "valet key", para obter acesso limitado a recursos usando o OAuth2, utiliza-se um access token (token de acesso), que permite usufruir recursos de terceiros de forma segura.

A TOTVS utilizará no novo serviço de login um dos fluxos propostos pelo framework Oauth2, abaixo a sua especificidade:

• O Grant Type para autenticação, autorização e permissionamento entre serviços (M2M). O Client é previamente cadastrado e permissionado e o Resource Server declara por meio de seeds seus recursos.

Para o ERP ficar dentro da especificação e ter o escopo adequado, a TOTVS seguirá a implementação de dois tipos de Grant:

a. Client Credentials

Esse tópico aborda a autorização entre serviços (M2M) onde o Client age em seu próprio nome Resource Server.

Figura 1 - Modelo de acesso com Client Credentials

Abaixo estão listados os componentes do desenho acima:

• IDM: Solução que garante a autenticidade do Resource Owner

• Oauth Provider: Solução que assume o papel de Oauth Provider e atua como Authorization Server, esse componente tem a responsabilidade de assinar o access_token com chave assimétrica. O Authorization Server consome uma fila de propagação "Role x ClientId" produzida pelo componente RBAC que persisti para possibilitar a geração do access_token auto-contido com as "Roles" do ClientId. O Authorization Server deve verificar a base para invalidação do clientId de modo que o mesmo ao tentar renovar o access_token utilizando seu refresh_token ou autorizar seja invalidado pelo Oauth Provider;

• RBAC: Esse componente é responsável por gerir as permissões possibilitando termos uma relação de "Role x Grant". A responsabilidade de verificação desse componente é classificada como extremamente crítica. A solução permite que o RBAC tenha consistência eventual delegando a verificação de "Grant x ClientID" para uma camada na aplicação (Resource Server);

• Resource Server (APP 2): A aplicação que hospeda o recurso tem a responsabilidade de enviar suas Grants para o RBAC via fila. Esse componente também deve consumir a fila de propagação de "Role x Grant" e gravar os dados recebidos para possibilitar a verificação de permissão das "Roles" que estarão auto-contidas no access_token. O Resource Server tem posse da chave pública para a verificação do access_token. Percebe-se que é necessário a construção de uma abstração para as aplicações;

• Client (APP 1): O Client é o consumidor do recurso e assume o papel de Resource Owner quando o "grant_type" é client_credentials, com isso, o Client precisa das credenciais client_id e client_secret gerados no momento do registro no Oauth Provider. Assumindo que o Client é o próprio Resource Owner não há a necessidade de delegação de acesso.

b. Resource Owner Password Credentials

A proposta aborda a autorização entre usuário Resource Owner e Client. Nesse caso o Client assume o papel de Resource Server, com isso, ele hospeda os recursos.

Figura 2 - Modelo de acesso com Resource Owner Password Credentials

Abaixo estão listados os componentes do desenho acima:

• IDM: O mesmo do modelo anterior;

• Oauth Provider: O mesmo do modelo anterior;

• RBAC: O mesmo do modelo anterior;

• DAC: Esse componente é responsável por gerir as permissões a nível "granular" possibilitando que um usuário possa conceder a permissão para outro usuário;

• Resource Server (APP 2): O mesmo do modelo anterior

  • Nesse caso o Resource Server também é o Client. O Client gerencia o access_token e o Resource Server faz a verificação com a chave pública;

• Resource Owner: Nesse Grant Type o usuário é o responsável pelas ações no Resource Server, logo o mesmo pede uma autorização em seu nome;

  • A requisição de autorização é denominada grant_type=password onde o usuário passa suas credenciais para um Client do tipo confidencial. O Client por sua vez deve pedir uma autorização ao Oauth Provider e obter o access_token.