BTG Id

Autenticação

Os serviços disponibilizados pelas APIs BTG Pactual Empresas necessitam que o aplicativo do parceiro passe por um ou mais dos fluxos de autorização. Nesta seção você terá um overview sobre o básico de como funciona nosso servidor de autenticação BTG Id.
Atente-se às próximas seções para saber qual a utilização de cada um dos fluxos.

BTG ID

O BTG Id é a plataforma de autenticação e autorização do BTG Pactual Empresas e é por meio dele que os parceiros são concedidos acessos às nossas APIs.

Funcionamos com um sistema de permissões a nível de usuário, fazendo com que nenhum sistema possa acessar dados sem antes a permissão do usuário que terá seus dados acessados.

O BTG Id segue os protocolos OpenID Connect e OAuth 2.0, permitindo o uso de bibliotecas open source na linguagem ou plataforma de preferência do desenvolvedor.

Conceitos basicos

sequenceDiagram
    participant Client
    participant ResourceOwner as Resource Owner
    participant AuthorizationServer as Authorization Server
    participant ResourceServer as Resource Server

    Client->>ResourceOwner: Authorization Request
    ResourceOwner-->>Client: Authorization Grant

    Client->>AuthorizationServer: Authorization Grant
    AuthorizationServer-->>Client: Access Token

    Client->>ResourceServer: Access Token
    ResourceServer-->>Client: Protected Resource

Este é o fluxo padrão para a utilização das nossas APIs e podemos observar que existem quatro partes envolvidas:

Authorization Server:
O servidor de autorização é o modulo responsável pela garantia de identidade do usuário, conceção e revogação de acessos a certos recursos e emissão de tokens. Os tokens vem pra você em dois tipos: O Access Token e o Refresh Token
- Access Token: É o token emitido a partir das permissões concedidas pelo usuário final. Representa a autorização da aplicação de acessar certos dados de um usuário na API. Tem duração de 24h.
- Refresh Token: É o token emitido juntamente ao Access Token e é utilizado para renová-lo sem a necessidade de interação com o usuário final. Tem duração de 10 dias.(RENOVAVEL).
Um exemplo de response do Authorization Server contendo o Access Token e o Refresh token:

   {
        "access_token":"eyJhbGciOiJSUzI1NiIsInR",
        "refresh_token":"WV6G4HKBrv",
        "scope":"apps email openid profile webhooks",
        "id_token":"eyJhbGciOiJIUzI1NiJ9.eyJzd",
        "token_type":"Bearer",
        "expires_in":86400
   }

Resource Owner
Geralmente também usuário final, o Resource Owner é o detentor dos dados a serem acessados e é quem concede os acessos a certos recursos para o Client.
Client
Este é o aplicativo do parceiro, identificado por meio do Client Id, e é a parte do fluxo que solicita tokens para o Authorization Server, com base nas permissões do Resource Owner.
Resource Server:
Esta é a parte do fluxo onde estão localizados os dados do Resource Owner e aqui o ocorre a autenticação do Client com segurança e a liberação do acesso aos dados por meio do Access Token.