[Nova funcionalidade] Auth 2.0 Auth Code Flow para agregar cenários de uso diversos: conciliação, marketplace, etc...

[llatsch]

1 - No trecho abaixo do ANEXO II da API PIX, página 37, não fica claro se precisamos disponibilizar um endpoint público para o usuário recebedor a primeiro momento. Podemos gerar o token internamente no OAuth 2.0 e compartilhar as credenciais com o cliente utilizando os canais que julgarmos mais adequados?

"Por jornada de adesão, entende-se o processo por meio do qual um usuário recebedor passa a utilizar
os serviços de um PSP específico. Do ponto de vista da API Pix, tal processo deve incluir o fornecimento
de credenciais de acesso (Client_IDs e senhas) e de certificados ao usuário recebedor.
Cada PSP terá autonomia para definir a jornada de Adesão para os seus clientes, utilizando os canais
que julgar mais adequados"

2 - É necessário termos o endpoint /refresh no primeiro momento? Caso necessário, para Novembro, usuário recebedor não poderia apenas gerar um novo TOKEN no endpoint /token?

3 - Internamente na PAGs nós já estavamos em processo de construção do "Authorization Code Flow" do OAuth 2.0.
Podemos utilizar ele no cenário onde um eCommerce permite que um Marketplace realize transações em seu nome?

4 - Qual o método indicado pelo BC para realizar a autenticação e autorização nos endpoints /token e /refresh?
Podemos usar o Authorization Bearer com o access token que o usuário já possui?

5 - Precisamos respeitar o prefixo /oauth em /oauth/token e /oauth/refresh?

[ninrod]

odemos gerar o token internamente no OAuth 2.0 e compartilhar as credenciais com o cliente utilizando os canais que julgarmos mais adequados?

sim.

É necessário termos o endpoint /refresh no primeiro momento? Caso necessário, para Novembro, usuário recebedor não poderia apenas gerar um novo TOKEN no endpoint /token?

Não é necessário implementar o refresh token. Já apareceu uma issue sobre isso aqui, mas não consigo encontrar agora.

3 - Internamente na PAGs nós já estavamos em processo de construção do "Authorization Code Flow" do OAuth 2.0.
Podemos utilizar ele no cenário onde um eCommerce permite que um Marketplace realize transações em seu nome?

Na API Pix utiliza-se Credentials Flow.

4 - Qual o método indicado pelo BC para realizar a autenticação e autorização nos endpoints /token e /refresh?
Podemos usar o Authorization Bearer com o access token que o usuário já possui?

O /token serve para que o usuário recebedor obtenha um novo token, e o PSP recebedor só concede um novo token caso client_id + secret seja válido. O Authorization Bearer, que é onde o token está atribuído, seria para acessar os endpoints da API em si. Nada disso funcionará se não houver um túnel mTLS fechado entre as duas pontas.

5 - Precisamos respeitar o prefixo /oauth em /oauth/token e /oauth/refresh?

Precisa respeitar /token e tendo em mente que o fluxo utilizado é o credentials flow.

[felipedelima19]

Podemos gerar o token internamente no OAuth 2.0 e compartilhar as credenciais com o cliente utilizando os canais que julgarmos mais adequados?

sim.

Entendo que, se podemos gerar o token internamente, não há a necessidade de expormos o endpoint /token conforme especificado. Meu entendimento está correto? Não precisamos expor o endpoint /token?

3 - Internamente na PAGs nós já estavamos em processo de construção do "Authorization Code Flow" do OAuth 2.0.
Podemos utilizar ele no cenário onde um eCommerce permite que um Marketplace realize transações em seu nome?

Na API Pix utiliza-se Credentials Flow.

Usamos o Authorization Code Flow para modelos nos quais existem 3 partes envolvidas na operação, esse modelo é o mais adequado e largamente usado pelo mercado nessas situações. Por exemplo:

1- Vendedor acessa plataforma de e-commerce/marketplace
2- Vendedor autoriza a plataforma à acessar a API PIX em nome dele
3- Após autorização do vendedor, plataforma possuirá access token específico para este vendedor dentro desses escopos.

Dado o cenário acima, vejo que não é viável usarmos o modelo do Client Credentials Flow, pois pra isso, a plataforma teria que ter acesso à informações sensíveis dos lojistas, risco que não existe no Authorization Code Flow. Existe alguma orientação em relação à esse ponto?

4 - Qual o método indicado pelo BC para realizar a autenticação e autorização nos endpoints /token e /refresh?
Podemos usar o Authorization Bearer com o access token que o usuário já possui?

O /token serve para que o usuário recebedor obtenha um novo token, e o PSP recebedor só concede um novo token caso client_id + secret seja válido. O Authorization Bearer, que é onde o token está atribuído, seria para acessar os endpoints da API em si. Nada disso funcionará se não houver um túnel mTLS fechado entre as duas pontas.

Entendo que para acessar os endpoints da API PIX, realmente o usuário recebedor precisará do access token gerado pelo recurso /token.

Porém, antes de realizar a chamada no recurso /token, o usuário recebedor precisa criar um client em outro recurso, obtendo assim o client_id e o client_secret, que serão posteriormente usados nos endpoints /token e o /refresh.

Minha dúvida é, para criar o client, nós podemos determinar a forma de acesso à essa API?

[felipedelima19]

@ninrod Pode reabrir a issue ou melhor eu criar outra?

[ninrod]

Entendo que, se podemos gerar o token internamente, não há a necessidade de expormos o endpoint /token conforme especificado. Meu entendimento está correto? Não precisamos expor o endpoint /token?

Respondi errado. Você não pode gerar o token internamente, o que vc pode gerar é o client_id+secret internamente e passar para o usuário recebedor em onboarding.

[ninrod]

Usamos o Authorization Code Flow para modelos nos quais existem 3 partes envolvidas na operação, esse modelo é o mais adequado e largamente usado pelo mercado nessas situações. Por exemplo:
1- Vendedor acessa plataforma de e-commerce/marketplace
2- Vendedor autoriza a plataforma à acessar a API PIX em nome dele
3- Após autorização do vendedor, plataforma possuirá access token específico para este vendedor dentro desses escopos.
Dado o cenário acima, vejo que não é viável usarmos o modelo do Client Credentials Flow, pois pra isso, a plataforma teria que ter acesso à informações sensíveis dos lojistas, risco que não existe no Authorization Code Flow. Existe alguma orientação em relação à esse ponto?

2- Vendedor autoriza a plataforma à acessar a API PIX em nome dele

Acho que estamos falando de um outro fluxo aqui: O que seria "a plataforma de ecommerce/marketplace"? Quem seria exatamente o "vendedor", especificamente, ele possuiria conta em que PSP? Pode detalhar mais esse caso de uso?

[felipedelima19]

Usamos o Authorization Code Flow para modelos nos quais existem 3 partes envolvidas na operação, esse modelo é o mais adequado e largamente usado pelo mercado nessas situações. Por exemplo:
1- Vendedor acessa plataforma de e-commerce/marketplace
2- Vendedor autoriza a plataforma à acessar a API PIX em nome dele
3- Após autorização do vendedor, plataforma possuirá access token específico para este vendedor dentro desses escopos.
Dado o cenário acima, vejo que não é viável usarmos o modelo do Client Credentials Flow, pois pra isso, a plataforma teria que ter acesso à informações sensíveis dos lojistas, risco que não existe no Authorization Code Flow. Existe alguma orientação em relação à esse ponto?

2- Vendedor autoriza a plataforma à acessar a API PIX em nome dele

Acho que estamos falando de um outro fluxo aqui: O que seria "a plataforma de ecommerce/marketplace"? Quem seria exatamente o "vendedor", especificamente, ele taria conta em que PSP? Pode detalhar mais esse caso de uso?

Esse cenário é de um lojista usando uma plataforma de e-commerce como a VTEX, Loja Integrada, PrestaShop ou marketplaces como Magazine Luiza, Americanas e etc.

Nesse escopo, o vendedor tem uma conta no PSP e autoriza a plataforma ou o marketplace à acessar os recursos em nome do vendedor. Esse fluxo é bem similar ao de login social usado pelo Facebook, Google e etc.

Nesse modelo, quem faz a requisição ao PSP não é o próprio resource owner (lojista) e sim, a plataforma. Com isso, a plataforma precisa de uma autorização explícita do lojista, para que, quando a plataforma faça a requisição no PSP, essa requisição seja realizada em nome do lojista.

Esse fluxo pode ser visto na imagem abaixo:
https://docs.wso2.com/download/attachments/60493891/OAuth%20grant%20types%20-%20AuthorizationCode%20%281%29.png?version=1&modificationDate=1510603077000&api=v2

[rubenskuhl]

Mas esse fluxo só faz sentido em caso de split payment, não ? Se for, é algo a agregar neste issue: #66 .

Há algum cenário de uso onde não haja remuneração de intermediário onde isso faria sentido ?

[felipedelima19]

@rubenskuhl Não necessariamente a esse fluxo envolve split payments. As funcionalidades podem ser usadas em conjunto sim, mas isso seria uma opção da própria plataforma.

Dado que os recursos do API PIX envolvem o escopo de leitura, poderiam existir autorizações para realizar conciliações/integrações como LinkApi e etc, por exemplo, e outros tipos de funcionalidades que não seja necessariamente um pagamento com split.

[rubenskuhl]

@rubenskuhl Não necessariamente a esse fluxo envolve split payments. As funcionalidades podem ser usadas em conjunto sim, mas isso seria uma opção da própria plataforma.

Dado que os recursos do API PIX envolvem o escopo de leitura, poderiam existir autorizações para realizar conciliações/integrações como LinkApi e etc, por exemplo, e outros tipos de funcionalidades que não seja necessariamente um pagamento com split.

Citar um caso de uso que não envolva split payment pode ajudar a discussão desse tema... pq genericamente tudo é possível.

[ninrod]

Citar um caso de uso que não envolva split payment pode ajudar a discussão desse tema... pq genericamente tudo é possível.

@rubenskuhl , concordo.

@felipedelima19 , preciso de um caso de uso mais detalhado porque não consigo visualizar esse cenário sem o "split payments". Por exemplo, como a plataforma, em detalhes, obteria o "cut"?

[felipedelima19]

Citar um caso de uso que não envolva split payment pode ajudar a discussão desse tema... pq genericamente tudo é possível.

@rubenskuhl , concordo.

@felipedelima19 , preciso de um caso de uso mais detalhado porque não consigo visualizar esse cenário sem o "split payments". Por exemplo, como a plataforma, em detalhes, obteria o "cut"?

Um exemplo simples. A Equals (ou qualquer outra conciliadora) oferecer conciliação de transações Pix para usuários da sua plataforma.

Nesse modelo, a Equals solicitaria acesso à API PIX em nome do seu usuário para obter informações das transações e levar isso pra sua própria plataforma.

Usando a própria Equals como exemplo, a monetização não é feita no pagamento (usando split payments) e sim através de uma mensalidade (ou algum outro modelo, não vinculado ao split. Volumetria, por ex).

Ou seja, esse exemplo de conciliadoras mostra um cenário real no qual precisaríamos de um fluxo Authorization Code no OAuth2 e não envolve split payments.