Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Dúvida] OAuth ClientCredentials Flow #48

Closed
camiloavelar opened this issue Oct 6, 2020 · 6 comments
Closed

[Dúvida] OAuth ClientCredentials Flow #48

camiloavelar opened this issue Oct 6, 2020 · 6 comments
Assignees
Labels
bug Algo não está funcionando como deveria. FAQ-Pix aspectos relacionados à documentação da Pix, podendo transcender a API Pix segurança aspectos relacionados a segurança

Comments

@camiloavelar
Copy link

Estamos com algumas dúvidas em relação ao fluxo de autenticação ClientCredentials citado nas especificações 2.0.0 da API. Lendo a RFC 6749, na seção 4.4.3, diz que no fluxo ClientCrendentials não se deve emitir um refreshToken, até porque no fluxo de validação do refreshToken deve-se autenticar também o usuário, não sendo vantagem sobre o ClientCredentials.

Porém, na documentação atual da API existem dois endpoints
https://pix.example.com/oauth/token
https://pix.example.com/oauth/refresh
quer dizer que deveremos emitir um refreshToken no fluxo de clientCredentials?

@ninrod ninrod self-assigned this Oct 6, 2020
@ninrod ninrod added bug Algo não está funcionando como deveria. FAQ-Pix aspectos relacionados à documentação da Pix, podendo transcender a API Pix labels Oct 6, 2020
@ninrod
Copy link
Member

ninrod commented Oct 6, 2020

@camiloavelar bom dia.

Obrigado pelo reporte. É um erro e será consertado na 2.1.0.

Existe apenas o endpoint /token mesmo.

@ninrod ninrod added the segurança aspectos relacionados a segurança label Oct 6, 2020
@camiloavelar
Copy link
Author

Bom dia @ninrod.
Entendi, muito obrigado pela resposta!

@ninrod
Copy link
Member

ninrod commented Oct 6, 2020

@camiloavelar , apenas complementando, na RFC 6749 é apenas recomendado não enviar o refresh token, mas não é proibido:

NA RFC 2119 seção 4, temos:

  1. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
    there may exist valid reasons in particular circumstances when the
    particular behavior is acceptable or even useful, but the full
    implications should be understood and the case carefully weighed
    before implementing any behavior described with this label.

E na RFC 6749, seção 4.4.3, temos:

If the access token request is valid and authorized, the
authorization server issues an access token as described in
Section 5.1. A refresh token SHOULD NOT be included. If the request
failed client authentication or is invalid, the authorization server
returns an error response as described in Section 5.2.

De qualquer maneira, vamos seguir a recomendação e não explicitar que o refresh token deva ser enviado.

@ninrod
Copy link
Member

ninrod commented Oct 19, 2020

resolvido na 2.1.0

@ninrod ninrod closed this as completed Oct 19, 2020
@SoftNov
Copy link

SoftNov commented Apr 19, 2024

Bom dia!
Pessoal, alguém pode me ajudar? Estou tentando fazer a integração com as api de hml, mas preciso do client_id e client_secret, como posso obter eles? Já solicitei o credenciamento como iniciador de transações de pagamento, mas sem retorno ainda. Existe alguma forma de conseguir as clientCredentials pra ir realizando a integração?

@rubenskuhl
Copy link

Bom dia! Pessoal, alguém pode me ajudar? Estou tentando fazer a integração com as api de hml, mas preciso do client_id e client_secret, como posso obter eles? Já solicitei o credenciamento como iniciador de transações de pagamento, mas sem retorno ainda. Existe alguma forma de conseguir as clientCredentials pra ir realizando a integração?

Essas credenciais se obtém com o PSP, enquanto o credenciamento é com o BACEN... além disso, as APIs com os PSPs e com o BACEN são diferentes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Algo não está funcionando como deveria. FAQ-Pix aspectos relacionados à documentação da Pix, podendo transcender a API Pix segurança aspectos relacionados a segurança
Projects
None yet
Development

No branches or pull requests

4 participants