[PT] - Perfil CIBA de Segurança do Open Finance Brasil 2.0

Introdução

O padrão de API de nível financeiro fornece um perfil para OAuth 2.0 adequado para uso em serviços financeiros. O método OAuth é um padrão utilizado pelo cliente para validar o dono do recurso em um servidor de autorização usando um redirecionamento HTTP. As partes 1 e 2 desta especificação oferecem suporte a esse modelo de interação e são adequadas para casos de uso em que o proprietário do recurso está interagindo com o cliente em um dispositivo que ele controla que tem um navegador da Web. No entanto, há muitos casos de uso para iniciar pagamentos em que o proprietário do recurso não está interagindo com o cliente dessa maneira. Por exemplo, o proprietário do recurso pode querer autorizar um pagamento em um terminal de "ponto de venda" em uma loja ou posto de combustível.

Este documento aborda o perfil CIBA (Client Initiated Backchannel Authentication) ou Fluxo de Autenticação de Backchannel Iniciado pelo Cliente OpenID Connect que oferece suporte a esse método de interação desacoplada. A especificação CIBA permite que um cliente que obtenha conhecimento de um identificador para o usuário obtenha tokens do servidor de autorização. O consentimento do usuário é dado no Dispositivo de Autenticação do usuário mediado pelo servidor de autorização. Este documento traça o perfil da especificação CIBA para alinhá-lo com as outras partes do FAPI e fornecer recomendações de segurança para seu uso com APIs que exigem segurança de nível financeiro.

Embora seja possível codificar um OpenID Provider e um Relying Party a partir dos primeiros princípios usando essa especificação, o principal público dessa especificação são as partes que já possuem uma implementação certificada de API de nível financeiro: Client Initiated Backchannel Authentication Profile e desejam obter a certificação para o programa Brasil Open Finance.

Convenções Notacionais

As palavras-chave "deve", "não deve", "não deve", "não deve", "pode" e "pode" neste documento devem ser interpretadas como descrito na Parte 2 da Diretiva ISO. Essas palavras-chave não são usadas como termos do dicionário, de modo que qualquer ocorrência delas deve ser interpretada como palavras-chave e não deve ser interpretada com seus significados de linguagem natural.

1. Escopo

Este documento especifica o método de:

1. aplicações para obter tokens OAuth por meio de um fluxo de autenticação backchannel de forma apropriadamente segura para acesso de maior risco aos dados de uma maneira que atenda aos requisitos do Open Finance Brasil;

2. aplicativos que usam o OpenID Connect CIBA para sugerir a identidade do cliente.

Este documento é aplicável a todos os participantes do Open Finance no Brasil.

2. Referências normativas

Os seguintes documentos referenciados são indispensáveis para a aplicação deste documento. Para referências datadas, aplica-se apenas a edição citada. Para referências não datadas, aplica-se a última edição do documento referenciado (incluindo quaisquer alterações).

ISODIR2 - ISO/IEC Directives Part 2

RFC6749 - The OAuth 2.0 Authorization Framework

RFC6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage

RFC7636 - Proof Key for Code Exchange by OAuth Public Clients

RFC6819 - OAuth 2.0 Threat Model and Security Considerations

RFC7515 - JSON Web Signature (JWS)

RFC7519 - JSON Web Token (JWT)

RFC7591 - OAuth 2.0 Dynamic Client Registration Protocol

RFC7592 - OAuth 2.0 Dynamic Client Registration Management Protocol

BCP195 - Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)

OIDC - OpenID Connect Core 1.0 incorporating errata set 1

FAPI-CIBA - Financial-grade API: Client Initiated Backchannel Authentication Profile

OIDD - OpenID Connect Discovery 1.0 incorporating errata set 1

OIDR - OpenID Connect Registration 1.0 incorporating errata set 1

RFC8705 - OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens

JARM - Financial-grade API: JWT Secured Authorization Response Mode for OAuth 2.0 (JARM)

PAR - OAuth 2.0 Pushed Authorization Requests

JAR - OAuth 2.0 JWT Secured Authorization Request

FAPI-1-Baseline - Financial-grade API Security Profile 1.0 - Part 1: Baseline

FAPI-1-Advanced - Financial-grade API Security Profile 1.0 - Part 2: Advanced

FAPI-2-Baseline - Financial-grade API Security Profile 2.0 - Part 1: Baseline

FAPI-2-Advanced - Financial-grade API Security Profile 2.0 - Part 2: Advanced

FAPI-CIBA - Financial-grade API: Client Initiated Backchannel Authentication Profile

FAPI-BR – Open Finance Brasil Financial-grade API Security Profile 1.0

CIBA - OpenID Connect Client Initiated Backchannel Authentication Core

LIWP - OIDF FAPI WG Lodging Intent Working Paper

OBB-FAPI-DCR - Open Finance Brasil Financial-grade API Dynamic Client Registration Profile 1.0

RFC4648 - The Base16, Base32, and Base64 Data Encodings

3. Termos e definições

Para os fins deste documento, os termos definidos em RFC6749, RFC6750, RFC7636, OpenID Connect Core, CIBA e ISO29100 se aplicam.

4. Símbolos e termos abreviados

API - Application Programming Interface

OFBIS - Open Finance Brasil Initial Structure

CSRF - Cross Site Request Forgery

DCR - Dynamic Client Registration

FAPI - Financial-grade API

HTTP - Hyper Text Transfer Protocol

OIDF - OpenID Foundation

REST - Representational State Transfer

TLS - Transport Layer Security

MFA - Multi-Factor Authentication

5. Perfil de Segurança do Brasil Open Banking

5.1. Introdução

O perfil de segurança Open Finance Brasil especifica requisitos adicionais de segurança e identidade para recursos de API de alto risco protegidos pelo OAuth 2.0 Authorization Framework que consiste em RFC6749, RFC6750, RFC7636, FAPI-1-Baseline, FAPI-1-Advanced, FAPI-CIBA e outras especificações.

Este perfil descreve as provisões de segurança e recursos para um servidor e cliente que são necessárias para o programa Open Finance Brasil, definindo as medidas a serem abordadas:

• o requisito de transmitir a Solicitação de Contexto de Autenticação que foi executada por um OpenID Provider a um Cliente para permitir o gerenciamento apropriado do risco de conduta do usuário pelo client.

• a exigência de que os clientes afirmem um relacionamento de cliente pré-existente afirmando uma declaração de identidade do cliente como parte do fluxo CIBA.

5.2. Open Banking Brasil CIBA Provisões de segurança

5.2.1. Introdução

Open Finance Brasil tem requisito para adotar Cliente Initiated Back Channel Authentication como um meio de habilitar fluxos de trabalho de autenticação desacoplada. Além disso, esse perfil descreve o escopo específico, os requisitos de gerenciamento de clientes necessários para apoiar o ecossistema mais amplo do Open Finance Brasil.

Como um perfil do OAuth 2.0 Authorization Framework, este documento exige o seguinte para o perfil do Brasil Open Finance Security.

5.2.2. Servidor de autorização

O Servidor de Autorização deverá suportar as disposições especificadas na cláusula 5.2.2 do Financial-grade API CIBA Security Profile 1.0

Além disso, o Servidor de Autorização

1. O tempo de aceitação do consentimento na solicitação de Autorização recebida via CIBA permanecerá o mesmo definido para o fluxo via Fluxo Híbrido, respeitando as configurações do produto utilizado;

2. Deve assegurar que o ‘exp’ em todos os id_tokens gerados têm pelo menos 180 dias de duração;

3. O id_token pode ser utilizado no pedido de autorização através do parâmetro “id_token_hint";

4. Deve suportar CIBA poll mode;

5. Não deve suportar CIBA push mode;

6. Não deve suportar CIBA ping mode;

7. O cancelamento do id_token será realizado pela instituição titular da conta em casos de fraude ou por razões de segurança;

8. Novos pedidos de autenticação poderão ser negados pela instituição titular da conta em casos de fraude ou por razões de segurança;

9. Tabela de erro "HTTP 400 Bad Request":

• invalid_request: A solicitação indica que está faltando um parâmetro necessário, foi incluído um valor de parâmetro inválido, foi inclui um parâmetro mais de uma vez, contém mais de um parâmetro invalido ou está malformada.;

• invalid_scope: O escopo solicitado é inválido, desconhecido ou malformado;

• expired_id_token_hint: Caso enviado, o “hint” do id_token fornecido na solicitação de autenticação não é válido porque já expirou;

• unknown_user_id: O OpenID Provider não é capaz de identificar qual usuário final o Cliente deseja ser autenticado. Tanto por meio do “hint” fornecido na solicitação (id_token_hint) como pelos dados do consentimento;

• unauthorized_client: O Cliente não está autorizado a usar esse fluxo de autenticação.

• invalid_id_token_hint: Caso enviado, o id_token é inválido e não pode ser usado no fluxo.

10. Deve emitir ciba auth request acknowledgements (a resposta da consulta do auth_req_id) com prazo máximo respeitando  as configurações do produto utilizado, como definido para o fluxo via Hybrid Flow;

11. Validação,  Payload Id_token, pode ser validado, quando enviado, pelos parâmetros abaixo.

12. Parâmetros para validação de assinatura

5.2.3. Cliente confidencial

Além disso, o cliente confidencial

1. deve suportar o consentimento parametrizado do escopo de recursos do OAuth 2.0, conforme definido na cláusula 6.3.1 OIDF FAPI WG Lodging Intent Pattern

2. deve suportar tokens de atualização.

6. Considerações de segurança

Os participantes devem apoiar todas as considerações de segurança especificadas em todas as cláusulas e subcláusulas do [FAPI-BR] e FAPI-CIBA.

7. Considerações sobre compartilhamento de dados

Os participantes devem apoiar todas as considerações de compartilhamento de dados especificadas em [FAPI-BR].