O open banking acelerou a transição dos serviços financeiros tradicionais para o mundo digital. Os consumidores agora têm uma liberdade financeira significativa e podem acessar seus dados financeiros armazenados em bancos através de provedores terceirizados.

Dentro desse contexto, oferecer experiências digitais aprimoradas que sejam seguras, perfeitas e “sempre on”. Uma pesquisa recente da Qualtrics afirma que 89% das empresas que lideram com experiências de clientes têm um desempenho melhor do que seus concorrentes.

A propriedade dos dados dos consumidores não é mais um fator decisivo. No entanto, é vital que as empresas fintech forneçam aos consumidores um fluxo de usuário suave com foco em conveniência, usabilidade e segurança. Recentemente, o OpenID Connect introduziu uma nova especificação técnica conhecida como CIBA (Client-Started Backchannel Authentication, autenticação do backchannel iniciado pelo cliente) para superar esse desafio. Por favor, consulte a especificação aqui.

As equipes de tecnologia precisam considerar uma solução fora da caixa para apoiar o CIBA para melhorar a experiência do usuário final durante a autenticação e autorização.

Para explicar e fornecer exemplos, usaremos o WSO2 Open Banking 3.0 como uma tecnologia de implementação.

Termos-chave

Dispositivo de consumo (CD)

Um dispositivo que ajuda os consumidores a interagir com os serviços de open banking de um provedor de terceiros (TPP). Este pode ser um aplicativo web baseado em navegador oferecido por um provedor de serviços de pagamento ou conta no ecossistema de open banking.

Dispositivo de autenticação (AD)

Um dispositivo que ajuda os consumidores a interagir com o servidor de autorização (AS) de um banco para autenticar e autorizar suas identidades.

Por que CIBA?

OpenID Connect é uma das principais especificações que o open banking é construído. O open banking permite que o aplicativo de um provedor terceirizado inicie um fluxo de autorização em nome dos consumidores. Um consumidor é redirecionado para o servidor de autorização de um banco e, em seguida, se engaja em autenticação, autorização (consentimento) e é finalmente redirecionado de volta para o aplicativo TPP, juntamente com afirmações verificáveis para que o processo prossiga.

Fig.1 : Um diagrama de fluxo open banking amostra

A Figura 1 mostra um fluxo de open banking amostrado com base no OpenID Connect. É obrigatório que o consumidor interaja com o dispositivo de consumo para se autenticar com o servidor de autorização do banco e fornecer consentimento. Além disso, essa interação do consumidor com o TPP e o servidor de autorização é tratada via redirecionamentos HTTP. No entanto, os redirecionamentos do navegador são altamente vulneráveis a ataques. Se a interação do consumidor com o CD para autenticação e autorização for tratada através de um dispositivo diferente (AD), elimina a necessidade de redirecionamentos HTTP. É aqui que entra a CIBA.

Principais características no CIBA

Autenticação dissociada

Como prática geral, o usuário deve usar o mesmo dispositivo para autenticar e consumir um serviço. No entanto, com a CIBA, o processo de autenticação é dissociado. O dispositivo de consumo que executa o aplicativo de provedor de terceiros inicia a solicitação de autenticação e autorização do backchannel enquanto a autenticação e autorização reais é realizada em um dispositivo de autenticação separado — que pode ser qualquer dispositivo inteligente, como um telefone celular, smartwatch e sistema de ponto de venda.

Modos de solicitação de tokens

A CIBA define três modos de solicitação de token para o aplicativo TPP após a autorização de consentimento do consumidor.

Modo de enquete: Uma vez recebida a resposta para a solicitação de autenticação do CIBA, o aplicativo TPP deve pesquisar continuamente o ponto final do token do banco em condições limitantes de taxas.
Modo ping: Uma vez que o consumidor fornece autenticação a partir de seu dispositivo, uma notificação é enviada para o aplicativo TPP (dispositivo de consumo) do servidor de autorização do banco. Só então o aplicativo TPP enviará uma solicitação de token.
Modo push: Uma vez que o consumidor fornece sua autenticação a partir do dispositivo de autenticação, uma notificação é enviada para o aplicativo TPP do servidor de autorização do banco com o próprio token. Como isso vem com um risco de alta segurança, isso é restrito para uso em implementações de CIBA no domínio financeiro pela API de grau financeiro (FAPI) – Perfil de Autenticação de Backchannel Iniciado pelo Cliente.

Observe que o WSO2 Open Banking atualmente só suporta o modo de votação. Uma vez que o suporte para o modo ping não é obrigatório pela FAPI, ele será considerado para suporte em uma versão futura.

O fluxo CIBA explicado

A Figura 2 mostra um diagrama de sequência para o fluxo CIBA usando o WSO2 Open Banking 3.0. Alguns novos recursos relacionados ao CIBA foram implementados para lidar com as etapas 2, 3, 8 e 9, enquanto as etapas 4, 5, 6 e 7 são tratadas por um novo autenticador dissociado, também chamado de autenticador federado.

Fig.2 : Diagrama de Fluxo de Sequência CIBA

Vamos discutir um fluxo CIBA usando um caso de uso de exemplo. Suponha que um consumidor queira fazer uma compra no varejo online e opte por pagar através de seu banco. A transação seguirá estas etapas:

O aplicativo TPP, que fornece o serviço de pagamento para a loja online, inicia a solicitação de autenticação do backchannel para o ponto final de autenticação CIBA do banco.
A especificação CIBA define o ponto final para a autenticação do CIBA, introduzindo um novo tipo de subvenção e um tipo de resposta também. Neste ponto, o navegador (CD) do consumidor não é redirecionado para o ponto final de autorização do banco e continua a permanecer na página da loja online.
Depois de receber uma resposta bem-sucedida com um auth_req_id como referência, o aplicativo TPP começa a pesquisar o ponto final do token se o modo estiver sendo votado.
O consumidor deve receber uma notificação em seu telefone (AD) onde o aplicativo bancário on-line do banco está instalado.
Esta notificação é gerada assincronicamente pelo servidor de autorização do banco após responder ao pedido de autenticação do backchannel do TPP e enviada ao dispositivo pré-registrado do consumidor. O alerta está incluído com as informações de consentimento solicitadas a serem exibidas no aplicativo móvel.
O consumidor abre seu aplicativo e verifica detalhes da compra. Em seguida, eles negam ou concedem consentimento fornecendo sua autenticação biométrica, como uma impressão digital.
Com base na resposta recebida do dispositivo de autenticação, o servidor de autorização do banco atualiza o status de autorização do consentimento. Além disso, ele responde com um token para a próxima votação de token enviada pelo aplicativo TPP, se o consentimento for concedido.
Uma vez que este processo de autenticação do backchannel é concluído, o consumidor é mostrado o status de pagamento no site da loja online.

Benefícios do Compliance da CIBA no Open Banking

A capacidade de os consumidores fornecerem consentimento através de um fluxo fora de banda que mitiga os redirecionamentos tradicionais do site.
A flexibilidade para compartilhar informações críticas de identidade de forma segura.
O uso de dispositivos inteligentes permite a integração da tecnologia biométrica. Isso ajuda a equilibrar a segurança com conveniência e velocidade.
O futuro de um banco depende do uso de novas tecnologias para oferecer experiências bancárias inovadoras e sem atrito. Alcançar a conformidade com o CIBA ajuda significativamente nisso em um ecossistema bancário centrado no cliente em rápida mudança.
Experiências satisfatórias aos clientes, com a ajuda da CIBA, recompensarão os bancos com lealdade, confiança e fortes referências dos clientes.

Esperamos que este post ajude os leitores a entender mais sobre a CIBA e como essa especificação ajuda bancos e empresas financeiras a desenvolver soluções centradas no cliente. Para saber mais, visite nossa página de soluções.

Autor: Thilini Dinushika

Artigo Original