Authorization Code

sequenceDiagram
    participant Browser
    participant BTG_Id as BTG Id Server
    participant App
    App->>Browser: (A) Client Id & Redirect Uri
    Browser->>BTG_Id: (A) Client Id & Redirect URI
    BTG_Id-->>Browser: Login Page
    Browser->>BTG_Id: (B) User authenticates
    BTG_Id->>Browser: (C) Authorization Code
    Browser->>App: (C) Authorization code
    App->>BTG_Id: Authorization Code, Redirect URI, Client Id & Secret 
    BTG_Id->>App: Access_token, refresh_token

🚧
Sandbox vs Produção
Os tokens possuem algumas especificidades com base no ambiente em que foram emitidos. Isto permite o funcionamento dos ambientes em paralelo e sem interação entre si, aumentando assim a segurança e garantindo que eventuais problemas não afetem ambos os ambientes simultaneamente.
É de suma importância que seja realizada a leitura dos artigos referentes aos ambiente de Produção e Sandbox.
Segue breve resumo das especiificidades mencionadas acima:
Sandbox

Tokens gerados no ambiente de sandbox permitem que o consentimento seja dado somente para a empresa dedicada ao funcionamento do ambiente;

O companyId e accountId utilizados nas requisições, além das demais claims do token irão derivar do CNPJ 30306294000145;

Qualquer usuário com permissão de desenvolvedor ou superior pode realizar o login no fluxo para emitir este token.

Produção

Token gerados no ambiente de produção permitem que o consentimento seja dado para a empresa em que o aplicativo está criado(First-party) ou para qualquer empresa em que o usuário que realizou o login esteja vinculado(Third-party);

O companyId e accountId utilizados nas requisições serão o da empresa para qual o consentimento foi dado;

Apenas o login de um usuário operador ou superior irá resultar em um token válido. Utilizar um usuário desenvolvedor acarretará em erro ao realizar as chamadas nas APIs.

Este é o fluxo padrão do Authorization Code necessário para a obtenção do Access Token e Refresh Token. Neste seção vamos destrinchar todo o fluxo, de forma a proporcionar para você desenvolvedor a experiencia mais tranquila possível.

Primeiramente a aplicação envia para o servidor de autenticação o Client Id e o Redirect URI cadastrado juntamente com os escopos autorizados pelo usúario final, conforme exemplo:
```
GET /oauth2/authorize?client_id={client_id}&response_type=code&redirect_uri={redirect_uri}&scope={scope}&prompt=login HTTP/1.1
Host: id.btgpactual.com
```
Em resposta, caso o processo sejá autorizado, o servidor de autenticação retorna o Authorization Code conforme abaixo:
```
HTTP/1.1 302 Found
Location: {redirect_uri}?code={authorization_code}&iss=https%3A%2F%2Fid.btgpactual.com
```

Após receber o Authorization Code, deve ser feita a requisição do Access Token conforme exemplo abaixo:

POST /oauth2/token HTTP/1.1
Host: id.btgpactual.com
Content-type: application/x-www-form-urlencoded
Authorization: Basic <client_id:client_secret> // Base 64 encoded

 code={authorization_code}&redirect_uri={redirect_uri}&grant_type=authorization_code

Nesta parte, os servidores de autenticação e autorização do BTG Id irão verificar a validade das informaçoes enviadas e, caso não hajam erros ou codigos inválidos, o servidor devolvera o Access Token e o Refresh Token junto a outras informações pertinentes como o escopo da autorização, o id do token, o tipo do token e a duração do token:

HTTP/1.1 200 OK
Content-Type: application/json

{
 "access_token":"eyJhbGciOiJS",
 "refresh_token":"WV6G4HKBr",
 "scope":"apps email openid profile webhooks",
 "id_token":"eyJhbGciOiJIUzI1NiJ9.eyJ"
 "token_type":"Bearer",
 "expires_in":86400
}

A partir daqui, já com seu Access Token em mãos, você pode consumir a APIs conforme permitido pelo usuário final!