| Índice | ||||
|---|---|---|---|---|
|
Prefácio
The normative version in English
...
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 5.2.2.3;
deveria suportar o atributo acr "urn:brasil:openbanking:loa3" como definido no item 5.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 de 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 (JWT ou opaco) sem prazo de validade associadonos cenários onde o mesmo é necessário.
5.2.2.1. Token de ID como assinatura separada
...
Deve obrigatoriamente criptografar o id_token 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, 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.
...
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:
...
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;
...
Este perfil define o escopo dinâmico do OAuth 2.0 "consentimento" da seguinte maneira:
string 'consent'consent’ ou ‘recurring-consent’; e
delimitador de dois pontos ":"; e
Consent API REST Resource Id retornado por uma criação bem-sucedida de Open Finance Consent Resource;
...
deve apenas emitir refresh_tokens quando vinculados a um consentimento ativo e válido;
Não deve emitir refresh_token quando o consentimento estiver no status “CONSUMED” (para fase 3);
Deve emitir um access_token por meio de um grant_type do tipo client credentials no status “CONSUMED” (para fase 3).
só deve compartilhar o acesso aos recursos quando apresentado access_token vinculado a um consentimento ativo e com o status "AUTHORISED“. Para tokens gerados com o scope: payments ou recurring-payments, o status do consentimento não será validado.;
No cenário de recebimento de token inválido, deve ser retornado status code 401.
deve revogar os refresh tokens e, quando aplicável, os access tokens quando o Consentimento (Consent Resource) relacionado for apagado;
deve garantir que os access tokens são emitidos com os scopes necessários para permitir acesso aos dados especificados em elemento Permission do Consentimento (Consent Resource Object) relacionado;
não deve rejeitar pedido de autorização com scopes além do necessário para permitir acesso a dados definidos em elemento Permission do Consentimento (Consent Resource Object) relacionado;
pode reduzir o escopo solicitado para um nível que seja suficiente para permitir o acesso aos dados definidos em elemento Permission do Consentimento (Consent Resource Object) relacionado;
deve manter registros sobre o histórico dos consentimento para permitir a adequada formação de trilhas de auditoria em conformidade com a regulação em vigor;
deve retornar falha na autenticação e o código de retorno _accessdenied no parâmetro erro (como especificado na seção 4.1.2.1 da RFC6749) caso o CPF do usuário autenticado não seja o mesmo indicado no elemento loggedUser do Consentimento (Consent Resource Object);
deve retornar falha na autenticação e o código de retorno _accessdenied no parâmetro erro (como especificado na seção 4.1.2.1 da RFC6749) caso o elemento businessEntity não tenha sido preenchido no Consentimento (Consent Resource Object) relacionado e o usuário tenha selecionado ou se autenticado por meio de credencial relacionada à conta do tipo Pessoa Jurídica (PJ);
deve condicionar a autenticação ou seleção de contas do tipo PJ à consistência entre o CNPJ relacionado à(s) conta(s) e o valor presente no elemento businessEntity do Consentimento (Consent Resource Object). Em caso de divergência deve retornar falha na autenticação e o código de retorno access_accessdenied denied no parâmetro erro (como especificado na seção 4.1.2.1 da RFC6749);
deve emitir refresh_refreshtoken com validade não inferior à validade do consentimento ao qual está relacionado, respeitado os demais critérios acima.
...