Introdução ao Fluxo CIBA

O CIBA (Client Initiated Backchannel Authentication) é um fluxo de autenticação desacoplada que permite à Instituição Receptora de Dados (Receptora) solicitar o consentimento de um usuário sem redirecioná-lo para o ambiente da Instituição Transmissora de Dados (Transmissora). No Open Finance Brasil, ele é definido pelo perfil CIBA-BR e aplicado, nesta documentação, à autorização de consentimentos de dados cadastrais e transacionais. Para o fluxo de pagamentos, por hora, o Openfinance não irá aplicar este protocolo.

No fluxo CIBA, a Receptora inicia a autenticação por uma chamada entre servidores, o usuário autentica e aprova o consentimento diretamente no canal digital da Transmissora (aplicativo ou internet banking) e a Receptora é notificada quando há uma decisão. Perceba que:

• o usuário não precisa estar na sessão ou no dispositivo da Receptora no momento da aprovação (fluxo desacoplado);
• a autenticação e a aprovação acontecem de forma assíncrona, no canal da Transmissora; e
• a Receptora só obtém os tokens de acesso após a aprovação do consentimento.

Quando utilizar o CIBA

O CIBA é especialmente indicado para os cenários em que o redirecionamento do usuário não é viável ou não é desejado:

• aplicações server-side, sem interface web;
• jornadas B2B e de clientes pessoa jurídica, com múltiplos aprovadores; e
• jornadas com menor atrito de entrada, como solicitações de compartilhamento iniciadas por link ou SMS.

CIBA e Hybrid FlowOs dois fluxos autorizam o mesmo tipo de consentimento. O que muda é a forma como o usuário chega à autenticação e como a Receptora é informada do resultado.

Conceitos principais

Visão geral da jornada

1. O usuário manifesta, no ambiente da Receptora, a intenção de compartilhar seus dados;
2. A Receptora obtém um token de acesso sistêmico (client_credentials) e cria o consentimento na Transmissora;
3. A Receptora solicita a autenticação CIBA (POST /bc-authorize) e recebe o auth_req_id (inicio da jornada CIBA);
4. A Transmissora notifica o usuário (ou os aprovadores), que se autentica e aprova ou rejeita o consentimento no canal digital da Transmissora;
5. A Transmissora envia o PING à Receptora, informando que há uma decisão;
6. A Receptora troca o auth_req_id por access_token, id_token e refresh_token (POST /token); e
7. A Receptora passa a consumir as APIs de dados, respeitando os escopos autorizados e a validade do consentimento.

Para o detalhamento de cada mensagem, consulte o Diagrama de sequência: Fluxo CIBA.

Segurança CIBA no Open Finance Brasil se apoia nos mesmos pilares de segurança das demais jornadas:

• autenticação mútua (mTLS) com certificados BRCAC;
• autenticação do cliente via private_key_jwt;
• request object assinado pela Receptora; e
• access tokens vinculados ao certificado da Receptora (certificate-bound).

Ciclo de vida do consentimento e obtenção dos tokens, a Receptora deve observar que:

• o access_token deve ser renovado com o refresh_token antes de expirar;
• a validade do consentimento (expirationDateTime) não é estendida pela emissão de tokens; e
• o usuário pode revogar o consentimento a qualquer momento no canal da Transmissora, o que bloqueia novos acessos com o access_token;
• o consentimento passa a ter 24 horas para ser aprovado considerando a data de criação do mesmo;
• será permitida a troca do fluxo Hybrid Flow para o fluxo CIBA de um consentimento previamente criado. Esta jornada tem como objetivo aumentar a taxa de conversão.

Referências

• Jornadada de Dados do Cliente com CIBA - v1.0.0-beta2
• CIBA-BR v2.1.0-beta2 - Open Finance Brasil Client Initiated Backchannel Authentication
• CIBA-BR v2.1.0-beta2 - Guia de Implantação