| Í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 (JWT ou opaco) sem prazo de validade nos cenários onde o mesmo é necessário.
...
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:
...
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_denied no parâmetro erro (como especificado na seção 4.1.2.1 da RFC6749);
deve emitir refresh_token com validade não inferior à validade do consentimento ao qual está relacionado, respeitado os demais critérios acima.
...