Comparação de Páginas

...

Além dos requisitos descritos nas disposições de segurança do Open Finance Brasil, o Servidor de Autorização

1. deve apenas emitir refresh_refreshtokens quando vinculados a um consentimento ativo e válido;

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

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

2. só deve compartilhar o acesso aos recursos quando apresentado access_accesstoken vinculado a um consentimento ativo e com o status "AUTHORIZED"AUTHORISED“. Para tokens gerados com o scope: payments, o status do consentimento não será validado.;

   1. No cenário de recebimento de token inválido, deve ser retornado status code 401.

3. deve revogar os refresh tokens e, quando aplicável, os access tokens quando o Consentimento (Consent Resource) relacionado for apagado;

4. 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;

5. 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;

6. 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;

7. 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;

8. 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);

9. 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);

10. 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 _accessdenied no parâmetro erro (como especificado na seção 4.1.2.1 da RFC6749);

11. deve emitir _refreshtoken com validade não inferior à validade do consentimento ao qual está relacionado, respeitado os demais critérios acima.

...