ninrod
commented
4 years ago boa tarde @dncosta
Esse usuário vai em seguida, enviar a plataforma o accessToken de alguma forma (email, formulário, etc). Aqui eu vejo uma falha de segurança no compartilhamento a cadastro manual de chaves. Tanto na geração, quanto no refresh do token (que aliás pode causar downtime na integração da plataforma com o PSP).
O RO não envia o access_token para a plataforma. O RO fornece os client_id+secret para a plataforma. Ele compra ou adquire o suporte do software da plataforma e configura suas credenciais neste software. O software da plataforma age em nome do RO. Para todos os efeitos, do ponto de vista do RS, o software da plataforma é o RO.
Alternativamente, esse usuário poderia compartilhar o secret o client_id e deixar a plataforma criar os accessTokens. Aqui também existe uma falha de segurança, pois a plataforma poderia gerar tokens e determinar os escopos inadivertidamente em nome do usuário.
a "plataforma" não determina escopos no endpoint /token. Os escopos já foram determinados previamente em onboarding.
O fluxo ideal para atender esse tipo de situação é o Authorization Code Flow.
Não existe a figura do Relying Party aqui. O RO conhece e confia plenamente na "plataforma", portanto a "plataforma" não é um RP e não se aplica o Authorization Code flow: a "plataforma" é o RO e age em seu nome. Nao existe, por exemplo, aqui neste contexto, a questão de o RP redirecionar o RO para um AS. É uma comunicação "Machine to Machine", o RO não está presente exceto na configuração inicial.
O usuário dá permissão ao client da plataforma para gerar um accessToken com scopes específicos.
a "permissão" ao client da plataforma é dada quando o RO fornece client_id + secret para o software da plataforma.
Adicionalmente, informo que este debate já ocorreu, inclusive no âmbito do GT-Seg, com a participação dos PSPs, e foi desta maneira encaminhado: mTLS + Oauth2 com credentials flow. Não há espaços para modificações no entendimento, neste ponto do projeto.
Dúvida aqui pessoal.
O Client credentials flow que usaremos pro PIX, prevê que um recebedor crie um
cliente em seguida chame o/tokenpra gerar oaccessToken, deterninando osscopesdo mesmo.Mas como funcionaria no cenário onde eu tenho um usuário recebedor quer receber PIX através de um terceiro?
Por exemplo. Imagina que temos:
No modelo de Client credencials flow:
secretoclient_ide deixar a plataforma criar osaccessTokens. Aqui também existe uma falha de segurança, pois a plataforma poderia gerar tokens e determinar os escopos inadivertidamente em nome do usuário.O fluxo ideal para atender esse tipo de situação é o Authorization Code Flow. Onde teríamos:
Dado que o accessToken gerado no Authorization Code Flow, segue os requisitos de segurança, segue a RFC e que ele atende modelos de negócio específicos não suportados de forma adequada pelo Client credentials flow, pq esse modelo não pode ser utilizado nas autenticações do PIX?
Qual a recomendação do Bacen pra atender esses cenários de forma que mitiguem os riscos mencionados?