CONTEÚDO

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

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.

Como exemplo, foi efetuado um cadatro para o acesso aos enpoints que pertencem ao /btb

A autenticação conforme credenciais de acesso geradas na tela de Configurações é necessária para obter o token JWT, para isto foi desenvolvido um endpoint que retorna dados para futuras utilizações:

Método: POST

URL: http://{{host}}:{{port}}/totvs-login-oauth2/oauth2/token?grant_type=client_credentials

Authorization: Basic Auth (Informar as credenciais Id cliente, Senha cliente parametrizadas em Propriedades → OAuth2)

Caso a autenticação seja realizada com sucesso, é retornado o token com o formato abaixo:

{
    "access_token": "eyJhbGciOiJSUzI1NiJ9.eyJzdWIiOiIwMjAwMTB3cmFBeEw0dmhhVFpncjJrTmVSOXRnNjYiLCJpYXQiOjE3MzM5MjU3OTIsImlzc3VlciI6ImRhdGFzdWwiLCJpc3MiOiJkYXRhc3VsIiwianRpIjoiNGEyZDA4NTItMjlkMi00NjYwLWFjZjEtNDVmODIyYTg0NzgyIiwiZXhwIjoxNzMzOTI3NTkyLCJhdWQiOiJsb2NhbGhvc3QuODA4MCIsInNjb3BlIjpbIi9idGIiXX0.KQh63ekGGKbR6V_hvhiKeOMBPADeaRiXY1G6u48aKdnYiD6RHNBH0kBkRsNH8P3Oyh-htctCITCB-S0sCGzbsRrqXH5AOkcUAdrBITBMMevH-UHjJm1non055SGUCtRX5XyWTNCl2KHCN6Wx6i3q7JEmoT_xNQA5c0nefIUCLrqzOCkTbaEs40BAl9iMR3EWcJL6x68N0jdxekuIHlP9vfOqs-I4UxBCGHWZxgp7lK-BRTeviXgiQRnEfIJSVtG9lAZI7pU_O9M1Cinp_4ZIZXLdXbcr3y1Q7PeiFSkRx7LXrYeRMDFDinBNa6vRwCRUnHOebTnibfhUR_m0uET6YA",
    "token_type": "Bearer",
    "expires_in": 1800,
    "refresh_token": "eyJhbGciOiJSUzI1NiJ9.eyJzdWIiOiIwMjAwMTB3cmFBeEw0dmhhVFpncjJrTmVSOXRnNjYiLCJpYXQiOjE3MzM5MjU3OTIsImlzc3VlciI6ImRhdGFzdWwiLCJpc3MiOiJkYXRhc3VsIiwianRpIjoiNTQ2NzQ3NTgtYTY3Ny00N2Q2LWI0OWEtOWRjY2I0OWM2ZGIzIiwiYWNjZXNzVG9rZW4iOiI0YTJkMDg1Mi0yOWQyLTQ2NjAtYWNmMS00NWY4MjJhODQ3ODIiLCJleHAiOjE3MzM5Mjc1OTJ9.g8hgwZfZdqlCsCTDVCNxqwRkVBlHqohkCa7bQphH60ntC--EJQJS2-Y0PpnHR6z6DAxnD3wTEb_yTL557c9spwcGKcd-9ZLXZxTSZD6vNCxhVpfbSTovLoP1Scjd4K8oDd9RIEV-rJXBcHYHYZm8CcUywoH_pf6yCaf9zTevHJ4r34yyTX7YgRNmKU5M2wBvH6EHjCo_VE7-7GLzMGE_CdrwzUU5Ib3X6TDS13epECXJ34XTI0Z6n-f_-4zAJikpftMCILVJ91MYlMA8rYHzWScZFBMtlx61Etx4gPqCDx73pK8A0t6Wj_7xWJNJ1ShfK9BCOyB3iG0n4VXWObeseQ",
    "scope": "/btb"
}

De posse com o token JWT gerado na etapa anterior, para acessar determinados recursos / endpoint, bastaria enviar o token na requisição com o formato Bearer Token:

Exemplo...

Método: GET

URL: http://{{host}}:{{port}}/api/btb/v1/properties/general

Authorization: Bearer (Informar o token JWT)