Running a request with OAuth2 configured show the result of the OAuth2 request instead of the result of the request itself

usebruno / bruno

Opensource IDE For Exploring and Testing Api's (lightweight alternative to postman/insomnia)

https://www.usebruno.com/

MIT License

27.64k stars 1.28k forks source link

Running a request with OAuth2 configured show the result of the OAuth2 request instead of the result of the request itself #3360

Open Oznup opened 4 weeks ago

Oznup commented 4 weeks ago

I have checked the following:

[X] I use the newest version of bruno.
[X] I've searched existing issues and found nothing related to my issue.

Describe the bug

I use Bruno to send requests on API protected with OAuth2. When I use directly the Bearer token, I run the request and I get the right response. When I configure OAuth2, I run the request and I get only the response from the OAuth2 server (with the token and the scopes).

.bru file to reproduce the bug

No response

Screenshots/Live demo link

OK Case using the bearer token, the response is correct OK_case Buggy case using OAuth2, see that the response contains an access_token, the structure is not the expected one. Clicking on "Get Access Token" or the right arrow on top right to send the request does the same. KO_case

helloanoop commented 3 weeks ago

Thank you for reporting this, @Oznup!

Bruno handles the OAuth2 flow a bit differently from other API clients. Currently, the process requires two separate requests: the first request manages the OAuth2 flow and stores the token in a variable, while the second request (the actual endpoint call) uses that token.

We understand this can be confusing, and we are actively working on improving the OAuth2 experience. In November, we plan to revamp the OAuth2 UI so that the entire flow happens seamlessly within a single interface.

In the meantime, please refer to our documentation for guidance on how to use OAuth2 with the current setup: https://docs.usebruno.com/auth/oauth2/overview

meequrox commented 3 weeks ago

We also encountered this peculiarity when my colleague executed a request to get a second access token from the .../token endpoint, and this request had OAuth 2.0 authorization configured (to fetch first access token). Instead of the second access token, he actually received the first one, which related to the configured authorization, and not to the result of the request execution. We thought that the authorization logic here is similar to the Postman logic, so it took a long time to find the problem.

It's great that this will be fixed, thanks!