Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.
Índice

Introdução

O Fluxo CIBA (Client - Initiated Backchannel Authentication) é uma alternativa ao Hybrid Flow, que traz a possibilidade de autenticação do usuário pagador no ambiente da Detentora de Conta em um dispositivo desacoplado, sem a necessidade de um redirect para Browser ou App no mesmo dispositivo onde a transação foi iniciadaé um protocolo de autenticação desacoplado em que Instituições Iniciadoras de Pagamento ou Receptoras de Dados recebem consentimentos dos usuários SEM realizar o fluxo FAPI Hybrid Flow (redirecionamento) em todas as interações.

O usuário é redirecionado via fluxo FAPI Hybrid Flow apenas uma única vez, onde o CIBA é ativado e por consequência os próximos pedidos de autorização serão por meio de um canal secundário - o backchannel - em que as Instituições Iniciadoras de Pagamento ou Receptoras de Dados se comunicam com o Servidor de Autorização da Instituição Detentora da Conta ou Transmissora de Dados para receber o consentimento do usuário.

O uso do FAPI Hybrid Flow para o vínculo inicial foi escolhido porque já é um processo conhecido pelo usuário e permite uma identificação via id_token em que os Servidores de Autorização já implementam nas Instituições Detentoras de Conta ou Transmissora de Dados.

Após o vínculo, nos próximos pedidos de consentimento, o usuário receberá um push notification, SMS, mensagem via WhatsApp, etc como canal de redirecionamentopara o aceite do consentimento.

Ao habilitar o fluxo CIBA os participantes devem implementar algumas diretrizes:

  1. O id_token é único e representa um cliente e conta;

  2. O tempo de aceite do consentimento sobre o pedido de Autorização recebido via CIBA deverá se manter o mesmo definido para o fluxo via Hybrid Flow, de 5 minutos;

  3. O payload de pagamento deve conter identificação que foi realizado via CIBA ou FAPI Hybrid Flow.

O fluxo CIBA está descrito em três quatro documentos técnicos que se complementam mutuamente, e fazem referências a outras especificações. Recomenda-se a consulta na seguinte ordem:

 

OpenID Connect Client-Initiated Backchannel Authentication Flow - Core 1.0 -https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html OpenID Connect Client-Initiated Backchannel Authentication Flow - Core 1.0 - Esta é a principal especificação do fluxo CIBA divulgada pela OpenID Foundation, contendo detalhes de implementação, requisitos e recomendações, e referências a outras especificações basais.

 Open Finance Brasil Financial-grade API Security Profile 1.0 Implementers Draft 3 - Open Finance Brasil Financial-grade API Security Profile 1.0 Implementers Draft 3 - Este é o perfil de regras e recomendações de autenticação e segurança proposto pelo GT de Segurança do Open Finance Brasil.

Financial-grade API: Client Initiated Backchannel Authentication Profile - https://openid.net/specs/openid-financial-api-ciba-ID1.html Draft-02: Financial-grade API: Client Initiated Backchannel Authentication Profile - Este é o perfil de regras e recomendações de autenticação e segurança proposto pela OpenID Foundation para implementações genéricas do fluxo CIBA.

 

Open Finance Brasil Financial-grade API CIBA Security Profile 1.0 - https://github.com/OpenBanking-Brasil/specs-seguranca/blob/main/open-banking-brasil-financial-api-CIBA-1_ID1.md Open Banking Brasil Financial-grade CIBA API Security Profile 1.0 Implementers Draft 3  - Este é o perfil de regras e recomendações de autenticação e segurança proposto pela Squad CIBA do Open Finance Brasil para implementação do fluxo CIBA para Iniciação de Pagamentos no cenário brasileiro.

 

As especificações acima permitem a implementação de três casos de uso, por sua vez descritos em mais detalhes no Manual de Experiência do Usuário, e explorados nas próximas seções deste manual de um ponto de vista de implementação técnica e integração.

Requisitos e Recomendações para implementação do fluxo CIBA 

  • O tempo de aceite / ação do Usuário Pagador sobre o pedido de Autorização recebido via CIBA deverá se manter o mesmo definido para o fluxo via Hybrid Flow, de 5 minutos.

  • Recomenda-se que os Participantes Detentores de Conta desenvolvam o fluxo com a possibilidade de tipificar/identificar unicamente transações realizadas via CIBA ou Hybrid Flow, permitindo o monitoramento e reporte dessas transações.

Opção 1 - Iniciação de Pagamento usando um Token de Identificação (id_token) na Iniciadora

Neste fluxo, assume-se que o Participante Iniciador de Pagamentos já possui um id_token que identifica o usuário (id_token conforme definido em https://openid.net/specs/openid-connect-core-1_0.html#IDToken ). O id_token pode ser obtido através de uma Iniciação de Pagamento prévia, se houver sido retornado na resposta da chamada ao recurso /token, onde se obtém também os access_token e refresh_token para o pagamento.

Para facilitar a implementação deste fluxo, esta especificação RECOMENDA que os Participantes Detentores incluam um passo na jornada de Confirmação de Pagamento para solicitar ao Usuário Pagador a geração de um id_token que será compartilhado com o Iniciador. Este passo poderá exibir ao usuário uma experiência que remeta ao conceito de “salvar conta para transações futuras”.

O id_token deve ser utilizado na chamada de autorização através do parâmetro “id_token_hint” (conforme https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html#rfc.section.7.1 )

Recomenda-se que o Participante Iniciador de Pagamentos exponha em sua interface uma identificação mascarada da conta utilizada na primeira transação, ao obter o id_token referente a essa conta. A identificação da conta pode ser obtida consultando o endpoint de Consentimento de Pagamentos (GET /payments/v2/consents/{consentId}, dado /data/debtorAccount/number)O protocolo CIBA é abrangente e permite diversos casos de uso. Nas próximas seções estão definidas as opções permitidas e seus detalhes. 

[SV] CIBA – Decoupled Flow EN

Introduction

The CIBA (Client Initiated Backchannel Authentication) is a decoupled authentication protocol where Payment Initiator Institutions or Data Receiving Institutions obtain user consents WITHOUT performing the FAPI Hybrid Flow (redirection) in every interaction.

The user is redirected via the FAPI Hybrid Flow only once, where CIBA is activated and consequently, the next authorization requests will be through a secondary channel - the backchannel - where Payment Initiator Institutions or Data Receiving Institutions communicate with the Authorization Server of the Account Holding Institution or Data Transmitting Institution to receive the user's consent.

Using the FAPI Hybrid Flow for the initial link was chosen because it's already a known process by the user and allows identification via an id_token that Authorization Servers already implement in Account Holding Institutions or Data Transmitting Institutions.

After the link, in subsequent consent requests, the user will receive a push notification, SMS, WhatsApp message, or another channel to redirect and accept the consent.

When enabling the CIBA flow, participants must implement certain guidelines:

1.The id_token is unique and represents a client and account;

  1. The consent acceptance time for the Authorization request received via CIBA should maintain the same defined for the flow via Hybrid Flow, which is 5 minutes;

  1. The payment payload must contain identification that it was carried out via CIBA or FAPI Hybrid Flow.

The CIBA flow is described in four complementary technical documents and refers to other specifications. It is recommended to consult them in the following order:

OpenID Connect Client-Initiated Backchannel Authentication Flow - Core 1.0: This is the primary specification of the CIBA flow released by the OpenID Foundation, containing implementation details, requirements, recommendations, and references to other foundational specifications.

Open Finance Brasil Financial-grade API Security Profile 1.0 Implementers Draft 3: This is the rule profile and security authentication recommendations proposed by the Open Finance Brasil Security GT.

Financial-grade API: Client Initiated Backchannel Authentication Profile - Draft-02: This is the rule profile and security authentication recommendations proposed by the OpenID Foundation for generic implementations of the CIBA flow.

Open Finance Brasil Financial-grade API CIBA Security Profile 1.0 - Open Banking Brasil Financial-grade CIBA API Security Profile 1.0 Implementers Draft 3: This is the rule profile and security authentication recommendations proposed by the CIBA Squad of Open Finance Brasil for the CIBA flow implementation for Payment Initiation in the Brazilian scenario.

The CIBA protocol is comprehensive and supports various use cases. The following sections define the currently allowed options and their details.