BTG Id

Autenticación

Los servicios que ponen a disposición las APIs de BTG Pactual Empresas necesitan que la aplicación del socio pase por uno o más de los flujos de autorización. En esta sección tendrás una visión general sobre lo básico de cómo funciona nuestro servidor de autenticación BTG Id.
Presta atención a las próximas secciones para saber cuál es la utilización de cada uno de los flujos.

BTG ID

BTG Id es la plataforma de autenticación y autorización de BTG Pactual Empresas y es por medio de ella que se les conceden a los socios accesos a nuestras APIs.

Funcionamos con un sistema de permisos a nivel de usuario, haciendo que ningún sistema pueda acceder a datos sin antes contar con el permiso del usuario cuyos datos serán accedidos.

BTG Id sigue los protocolos OpenID Connect y OAuth 2.0, permitiendo el uso de bibliotecas open source en el lenguaje o plataforma de preferencia del desarrollador.

Conceptos básicos

Este es el flujo estándar para la utilización de nuestras APIs y podemos observar que existen cuatro partes involucradas:

1. Authorization Server:
   El servidor de autorización es el módulo responsable de la garantía de identidad del usuario, la concesión y revocación de accesos a ciertos recursos y la emisión de tokens. Los tokens llegan a ti en dos tipos: El Access Token y el Refresh Token

   • Access Token: Es el token emitido a partir de los permisos concedidos por el usuario final. Representa la autorización de la aplicación para acceder a ciertos datos de un usuario en la API. Tiene una duración de 24h.
   • Refresh Token: Es el token emitido junto con el Access Token y se utiliza para renovarlo sin necesidad de interacción con el usuario final. Tiene una duración de 10 días.(RENOVABLE).

   Un ejemplo de response del Authorization Server que contiene el Access Token y el Refresh token:

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

2. Resource Owner
   Generalmente también usuario final, el Resource Owner es el titular de los datos que serán accedidos y es quien concede los accesos a ciertos recursos al Client.

3. Client
   Esta es la aplicación del socio, identificada por medio del Client Id, y es la parte del flujo que solicita tokens al Authorization Server, con base en los permisos del Resource Owner.

4. Resource Server:
   Esta es la parte del flujo donde se encuentran los datos del Resource Owner y aquí ocurre la autenticación del Client con seguridad y la liberación del acceso a los datos por medio del Access Token.