Revisão da política de autorização utilizando authorization code e client credentialsAtualização de testes do motor de conformidade funcional da API de Payments v2.0.0 para o fluxo client credentials

Informe #352 | 04.04.2023

Revisão da política de autorização utilizando authorization code e client credentials

Informamos que houve alteração na documentação de segurança quanto à utilização do refresh token para operações e transações da fase 3. Para padronização, foram elaboradas as seguintes regras para o serviço:

Uso do refresh token ocorre em status Authorized (fases 2 e 3) e uso de client credentials para verificar status a partir de “consumed” (fase 3):

Fluxo de autorização client credentials apresenta escopo limitado, com menor privilégio. Por sua vez, o fluxo com refresh tokens apresenta privilégios acima do necessário;

Incluídos na seção 7.2.2 do Perfil de Segurança do Open Finance Brasil os subitens 1.1 e 1.2 com a seguinte redação:

Não deve emitir refresh_token quando o consentimento estiver no status “CONSUMED” (para fase 3);

1.2 Deve emitir um access_token por meio de um grant_type do tipo client credentials no status “CONSUMED” (para fase 3).

A informação incluída está disponível na área do desenvolvedor, na documentação do perfil de segurança:  Acesse aqui

Adicionalmente, informamos que, para o endpoint PATCH/pix/payments nos casos de cancelamento de pagamento, serão aceitos como política de autorização o authorization_code e o client_credentials.

Em complemento, comunicamos que foram adicionados dois itens à lista de problemas conhecidos da fase 3, conforme segue:

BCLOG-F03-V02-009

API/Sessão: API Payments

Endpoint: GET/pix/payments/{paymentId}

Campo: Security profile

Qual o problema:

security:

- OAuth2AuthorizationCode:

- openid

- payments

- OAuth2ClientCredentials:

- payments

Como deveria ser:

security:

- OAuth2ClientCredentials:

- payments

Orientação: Garantir que a API seja acessível apenas pela estrutura de segurança:

security:

- OAuth2ClientCredentials:

- payments

A exclusão do modelo de segurança terá testes funcionais, a serem publicados por Sandbox e com orientação das datas de execução pelas instituições publicada em um informe

BCLOG-F03-V02-010

API/Sessão: API Payments

Endpoint: PATCH/pix/payments/{paymentId}

Campo: Security profile

Qual o problema: Os testes de autenticação para o endpoint PATCH de cancelamento de uma iniciação de pagamento foram implementados via authorization code, porém na especificação está definido para utilizar client credentials

Como deveria ser: Utilizar apenas client credentials

Orientação: Serão aceitos client credentials e authorization code para não haver uma quebra abrupta

Testes serão criados para o fluxo via client credentials para certificar as detentoras de conta que estão aderentes à especificação e será realizado um informa para aviso as iniciadoras com as orientações necessárias

Atualização de testes do motor de conformidade funcional da API de Payments v2.0.0 para o fluxo client credentials

Três testes serão atualizados no motor de conformidade para fluxo via client credentials para certificar as detentoras de conta que estão aderentes à especificação.

Os módulos que serão ajustados são:

payments-pixscheduling-patch-iniciadora-v2

payments-pixscheduling-patch-unhappy-v2

payments-contenttype-jwt-refreshtoken-v2

O cronograma de execução dos testes no motor de conformidade (ambiente sandbox) é:

Até 10/04/2023: Disponibilização dos testes

Até 17/04/2023: Execução dos testes por todas as detentoras de conta

Até 24/04/2023: Execução com sucesso dos testes por todas as detentoras

A exclusão do modelo de segurança access_token terá testes funcionais, a serem publicados pelo Squad Sandbox e com orientação das datas de execução pelas instituições publicada em um Informe posteriormente.