...
Este documento também está disponível em inglês
A Estrutura Inicial do Open Finance Brasil é responsável por criar padrões e especificações necessários para atender aos requisitos e obrigações da Legislação do Brasil Open Finance originalmente delineada pelo Banco Central do Brasil. Existe a possibilidade de que alguns dos elementos deste documento possam estar sujeitos a direitos de patente. A OFBIS não será responsável pela identificação de qualquer ou todos esses direitos de patente.
...
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
...
distribuirá metadados de descoberta (como o ponto de extremidade de autorização) por meio do documento de metadados, conforme especificado em OIDD e [RFC8414]
deve apoiar o parâmetro de sinistros conforme definido na cláusula 5.5 OpenID Connect Core
deve apoiará o acr "urn:brasil:openbanking:loa2" conforme definido na cláusula 5.2.2.4 do FAPI-BR
deve suportar o acr "urn:brasil:openbanking:loa3" conforme definido na cláusula 5.2.2.4 do [FAPI-BR]]
deve implementar o ponto de extremidade UserInfo, conforme definido na cláusula 5.3 OpenID Connect Core
deve oferecer suporte ao consentimento de escopo de recurso OAuth 2.0 parametrizado, conforme definido na cláusula 6.3.1 OIDF FAPI WG Lodging Intent Pattern
deve suportar tokens de atualização
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, de 5 minutos
Deve assegurar que o ‘exp’ em todos os id_tokens gerados têm pelo menos 180 dias de duração
O id_token deve ser utilizado no pedido de autorização através do parâmetro “id_token_hint"
Deve suportar CIBA poll mode
Não deve suportar CIBA push mode
Não deve suportar CIBA ping mode
O cancelamento do id_token será realizado pela instituição titular da conta em casos de fraude ou por razões de segurança.
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: 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 por meio do “hint” fornecido na solicitação (id_token_hint).
unauthorized_client: O Cliente não está autorizado a usar esse fluxo de autenticação.
invalid_id_token_hint: O id_token é inválido e não pode ser usado no fluxo
Deve emitir ciba auth request acknowledgements (a resposta da consulta do auth_req_id) com prazo máximo de 5 minutos, como definido para o fluxo via Hybrid Flow
Validação Payload Id_token
Parameters | Validation |
iss | O Servidor de Autorização deve estabelecer um identificador, ou conjunto de identificadores "iss" padrão para uso em transações CIBA. - O Servidor de Autorização não deve aceitar "iss" diferente de seu próprio identificador, ou conjunto de identificadores, padrão. |
sub | O Servidor de Autorização deve verificar se o identificador "sub" em questão já foi emitido para um cliente/conta, e se é válido dentro de seus requisitos. |
aud | O Servidor de Autorização não deve aceitar "aud" diferente do client_id de onde se origina a solicitação de autorização para o fluxo CIBA. |
exp | "exp" deve ser estabelecido de acordo com as políticas de risco da instituição Titular da Conta. O Servidor de Autorização não deve aceitar solicitações de autorização cuja data/hora seja maior que "exp". |
iat | Sem validações específicas |
auth_time | Sem validações específicas |
nonce | Sem validações específicas no Servidor de Autorização (AS) |
acr | Se presente, o AS só deverá aceitar valores iguais ou superiores aos requisitos de autenticação do Titular para autorizar operações de pagamento. |
amr | Se presente, o AS só deverá aceitar valores iguais ou superiores aos requisitos de autenticação do Titular para autorizar operações de pagamento. |
azp | O Servidor de Autorização não deve aceitar "azp" diferente do client_id de onde se origina a solicitação de autorização para o fluxo CIBA. |
Parâmetros para validação de assinatura
...
Parâmetros | Descrição | Condição | Valores recomendados |
alg | O parâmetro "alg" (algoritmo) identifica o algoritmo criptográfico usado para proteger o JWS/JWE. O valor de Assinatura JWS será inválido se o valor "alg" não representar um algoritmo suportado ou se não houver nenhuma chave compatível para o uso do algoritmo associado à entidade que assinou digitalmente o conteúdo. | Obrigatório | PS256 ou PS512 |
kid | O parâmetro "kid" (Key ID) indica qual chave foi usada para proteger o JWS/JWE. Esse parâmetro permite que os remetentes sinalizem explicitamente uma alteração de chave para os destinatários. O valor "kid" DEVE ser uma cadeia de caracteres que diferencia maiúsculas de minúsculas. Quando usado com um JWK, o valor "kid" é usado para corresponder a um valor de parâmetro "kid" do JWK. |
Obrigatório | ||
x5t | x5t#S256 | O parâmetro "x5t" ou "x5t#S256” (X.509 Certificate SHA-1/SHA-256 Thumbprint) é uma impressão digital SHA-1/SHA-256 codificada em base64url (hash) da codificação DER do certificado X.509 (RFC5280) correspondente à chave usada para assinar digitalmente o JWS. |
x5t#S256
Obrigatório | ||
typ | O parâmetro "typ" (Type) é usado por aplicativos JWS para declarar o tipo de mídia (IANA. MediaTypes) deste JWS completo. Destina-se ao uso pelo aplicativo quando mais de um tipo de objeto pode estar presente em uma estrutura de dados de aplicativo que pode conter um JWS; O aplicativo pode usar esse valor para eliminar a ambiguidade entre os diferentes tipos de objetos que podem estar presentes. |
Opcional | JWT |
5.2.3. Cliente confidencial
...