...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
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.
O fluxo CIBA está descrito em três 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 - 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.
Financial-grade API: Client Initiated Backchannel Authentication Profile - https://openid.net/specs/openid-financial-api-ciba-ID1.html - 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 - 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 usuário volta para o ambiente da iniciadora e insere o código gerado. Nesse momento acontece o fluxo de autenticação MTLS, gerando o access_token e o atributo de consentimento.
Na requisicao de POST /bc-authorize/, adicionamos um campo que é o login_hint, com o OTP da detentora:
Exemplo:
Requisição
POST /bc-authorize
Content-Type: application/x-www-form-urlencoded
scope=payment consent:[id_consent]&binding_message=<código_vinculo>
&client_notification_token=[8d67dc78-7faa-4d41-aabd-67707b374255]&login_hint=[OTP]
Reposta esperada
HTTP/1.1 200 OK
Content-type: application/json
{
"auth_req_id": "1231243123123423",
"expires_in": "360",
"interval":"2"
}
Com o Ok da requisição, a iniciadora deve solicitar ao usuario uma aprovação desse vinculo.
Após, iniciamos o processo do pagamento da transação, com o fluxo padrão de Payments (mencionado na documentação de Pagamentos).
...