...
Open Finance Brasil Financial-grade API Security Profile 1.0¶
Estas partes são destinados a serem usados com RFC6749, RFC6750, RFC7636, OIDC, FAPI-1-Baseline e FAPI-1-Advanced
...
deve realizar a autenticação do cliente utilizando private_key_jwt;
deve exigir requisições do tipo "pushed authorization requests" PAR;
deve publicar metadados de descoberta (incluindo a do endpoint de autorização) por meio do documento de metadado especificado em OIDD e [RFC8414] (".well-known");
deve suportar os parâmetros claims como definido no item 5.5 do OpenID Connect Core;
deve suportar o atributo acr "urn:brasil:openbanking:loa2" como definido no item Solicitando uma "claim" cnpj deste documento5.2.2.3;
deveria suportar o atributo acr "urn:brasil:openbanking:loa3" como definido no item Solicitando uma "claim" cnpj deste documento5.2.2.3;
deve implementar o endpoint "userinfo" como definido no item 5.3 do OpenID Connect Core;
deve suportar o escopo parametrizável ("parameterized OAuth 2.0 resource scope") consent como definido no item 6.3.1 de OIDF FAPI WG Lodging Intent Pattern;
pode suportar Financial-grade API: Client Initiated Backchannel Authentication Profile;
(requisito temporariamente retirado);
deve suportar refresh tokens;
deve emitir access tokens com o tempo de expiração entre 300 (mínimo) e 900 (máximo) segundos;
deve sempre incluir a claim acr no id_token;
deve suportar os valores code e id_token para o atributo response_type;
não deve permitir o recurso de rotação de refresh tokens;
deve garantir que em caso de compartilhamento do Servidor de Autorização para outros serviços, além do Open Finance, não divulgue e/ou possibilite o uso de métodos não certificados no ambiente do Open Finance;
deve garantir que as configurações divulgadas aos demais participantes através do OpenID Discovery (indicado pelo arquivo de Well-Known cadastrado no Diretório) sejam restritos aos modos de operação aos quais a instituição se certificou;
deve manter em suas configurações os métodos para os quais ainda haja clientes ativos;
deve atualizar os cadastros que utilizem métodos não certificados, através de tratamento bilateral entre as instituições envolvidas;
deve recusar requisições, para o ambiente do Open Finance, que estejam fora dos modos de operação ao qual a instituição certificou seu Servidor de Autorização;
o tempo mínimo de expiração do request_uri deve ser de 60 segundos;
deve recusar requisições que não apresentem o cabeçalho x-fapi-interaction-id em endpoints FAPIde recursos protegidos;
deve exigir a utilização de Proof Key for Code Exchange (PKCE);
deve exigir a utilização do subject_type “public”;
deve exigir a utilização do response_mode “fragment”;
Deve emitir refresh_tokens exclusivamente do tipo opaco e sem prazo de validade associado.
5.2.2.1. Token de ID como assinatura separada
...
Deve obrigatoriamente criptografar o id_token antes do envio ao cliente.nos momentos de call-back e chamada do endpoint de token
Para a criptografia do id_token deve ser utilizada chave disponível no JWKS informado no parâmetro jwks_uri durante o registro do , com o atributo “use”:”enc”, durante o registro do cliente, indicada através do cabeçalho kid do documento JWT;
O uso de outros cabeçalhos para indicação da chave utilizada, como x5u, x5c, jku ou jkw é vetado conforme definido na cláusula 2 OIDC.
...
Este perfil usa a definição oficial encontrada em: Analise requisitos de criptografia ID_TOKEN. Isso significa que o sub é um identificador nunca transferido ou alterado para o usuário final dentro da emissora (detentora/transmissora).
5.2.2.
...
3. Solicitando o "urn:brasil:openbanking:loa2" ou "urn:brasil:openbanking:loa3" Solicitação de contexto de autenticação
Esse perfil define "urn:brasil:openbanking:loa2" e "urn:brasil:openbanking:loa3" como novas classes de "Authentication Context Request" (ACR)
...
Para realizar autenticação por múltiplos fatores (MFA) é necessário que o usuário apresente, ao menos, dois diferentes fatores dos listados acima. Um mesmo fator usado mais de uma vez - por exemplo, a apresentação de suas senhas que ele conhece - não pode ser aceito como MFA.
5.2.
...
Um cliente confidencial deve apoiar as disposições especificadas na cláusula 5.2.3 de Financial-grade API Security Profile 1.0 - Part 2: Advanced,
Além disso, o cliente confidencial
...
2.4 Escopos obrigatórios no endpoint de descoberta (well-known)
O servidor de autorização, contidos em organizações que possuem a role DADOS, deve obrigatoriamente declarar os escopos abaixo em seu endpoint de descoberta (well-known), independentemente se a instituição forneça ou não os produtos referentes aos escopos abaixo listados:
invoice-financings
financings
loans
unarranged-accounts-overdraft
bank-fixed-incomes
credit-fixed-incomes
variable-incomes
treasure-titles
funds
exchanges
Os escopos não listados acima devem ser declarados caso a instituição forneça produtos referentes aos mesmos (ex: accounts, payments).
5.2.3. Cliente confidencial
Um cliente confidencial deve apoiar as disposições especificadas na cláusula 5.2.3 de Financial-grade API Security Profile 1.0 - Part 2: Advanced,
Além disso, o cliente confidencial
deve suportar objetos de solicitação encrypted;
deve suportar solicitações de autorização push (pushed authorization requests) PAR;
deve usar objetos de solicitação encrypted se não usar PAR;deve suportar o escopo de recurso OAuth 2.0 parametrizado consent conforme definido na cláusula 6.3.1 OIDF FAPI WG Lodging Intent Pattern;
deve suportar refresh tokens;
não deve incluir um valor específico na claim acr;
deve definir a claim acrcomo essential;
deve suportar todos os métodos de autenticação especificados no item 14 da seção 5.2.2 da Financial-grade API Security Profile 1.0 - Part 2: Advanced incluindo as diferentes combinações de métodos de encaminhamento dos Requests Objects (usando ou não PAR - item 11);
não deve permitir o recurso de rotação de refresh tokens;não deve solicitar requisições de autenticação que incluam um id_token_hint, visto que o id_token a ser utilizado pode conter Informação de Identificação Pessoal, que poderia ser enviada descriptografada através do cliente público;
deve enviar o cabeçalho x-fapi-interaction-id em endpoints FAP
...
6.1. Considerações sobre assinatura do conteúdo de mensagens (JWS)
Para garantir a integridade e o não-repúdio das informações tramitadas em API's sensíveis e que indicam essa necessidade na sua documentação, deve ser adotado a estrutura no padrão JWS definida na RFC7515 e que inclui:
Cabeçalho (JSON Object Signing and Encryption - JOSE Header), onde se define o algoritmo utilizado e inclui informações sobre a chave pública ou certificado que podem ser utilizadas para validar a assinatura;
Payload (JWS Payload): conteúdo propriamente dito e detalhado na especificação da API;
Assinatura digital (JWS Signature): assinatura digital, realizada conforme parâmetros do cabeçalho.
Cada elemento acima deve ser codificado utilizando o padrão Base64url RFC4648 e, feito isso, os elementos devem ser concatenados com "." (método JWS Compact Serialization, conforme definido na RFC7515).
O payload das mensagens (requisição JWT e resposta JWT) assinadas devem incluir as seguintes claims presentes na RFC7519:
aud (na requisição JWT): o Provedor do Recurso (p. ex. a instituição detentora da conta) deverá validar se o valor do campo aud coincide com o endpoint sendo acionado;
aud (na resposta JWT): o cliente da API (p. e. instituição iniciadora) deverá validar se o valor do campo aud coincide com o seu próprio organisationId listado no diretório;
iss (na requisição JWT e na resposta JWT): o receptor da mensagem deverá validar se o valor do campo iss coincide com o organisationId do emissor;
jti (na requisição JWT e na resposta JWT): o valor do campo jti deverá ser preenchido com o UUID definido pela instituição de acordo com a [RFC4122] usando o versão 4;
iat (na requisição JWT e na resposta JWT): o valor do campo iat deverá ser preenchido com horário da geração da mensagem e de acordo com o padrão estabelecido na RFC7519 para o formato NumericDate.
cty (na requisição JWT e na resposta JWT): o valor do campo cty deverá ser preenchido caso as operações de assinatura ou criptografia aninhadas não sejam empregadas, o uso desse parâmetro de cabeçalho não é recomendado. No caso de assinatura aninhada ou criptografia ser empregada, este parâmetro de cabeçalho deve estar presente; neste caso, o valor deve ser "JWT", para indicar que um JWT aninhado é transportado neste JWT. Embora os nomes dos tipos de mídia não diferenciem maiúsculas de minúsculas, é recomendável que "JWT" sempre seja escrito com caracteres maiúsculos para compatibilidade com implementações herdadas.
O content-type HTTP das requisições e respostas com mensagens JWS deve ser definido como: "application/jwt".
No cabeçalho JOSE deve constar os seguintes atributos:
alg - deve ser preenchido com o valor PS256";
kid - deve ser obrigatoriamente preenchido com o valor do identificador da chave utilizado para a assinatura;
typ - deve ser preenchido com o valor JWT.
Em caso de erro na validação da assinatura pelo Provedor do Recurso a API deve retornar mensagem de erro HTTP com status code 400 e a resposta deve incluir na propriedade code do objeto de resposta de erro especificado na API (ResponseError) a indicação da falha com o conteúdo BAD_SIGNATURE.
Erros na validação da mensagem recebida pela aplicação cliente (p. ex. iniciador de pagamento) devem ser registrados e o Provedor do Recurso (p. ex. instituição detentora de conta) deve ser notificado.
O receptor deve validar a consistência da assinatura digital da mensagem JWS exclusivamente com base nas informações obtidas do diretório, ou seja, com base nas chaves publicadas no JWKS da instituição no diretório.
As assinaturas devem ser realizadas com uso do certificado digital de assinatura especificado no Padrão de Certificados Open Finance Brasil;
A claim iat deve ser numérica no formato Unix Time GMT+0 com tolerância de +/- 60 segundos;
A claim do jti deve ser única para um clientId dentro de um intervalo de tempo de 86.400 segundos (24h), não podendo ser reutilizada neste período. Em caso de reutilização, deverá ser retornado o código de erro HTTP 403. Demais casos seguir instrução da RFC 6749, item 5.2;
...
Para JWS, clientes e servidores de autorização
devem usar o algoritmo PS256;
6.1.2. Considerações de algoritmo de criptografia
Para JWE, clientes e servidores de autorização
devem usar RSA-OAEP com A256GCM
6.1.3. Considerações sobre o uso seguro do Transport Layer Security
...
string 'consent'; e
delimitador de dois pontos ":"; e
Consent API REST Resource Id retornado por uma criação bem-sucedida de Open Finance Consent Resource;
Adicionalmente:
Consent Resource Id deve incluir caracteres seguros para url;
Consent Resource Id deve ser "namespaced";
Consent Resource Id deve ter propriedades de um nonce Nonce;
...