OAUTH2 auth is successful but token endpoint is returned instead of api endpoint

[wmlele]

Hello,

trying to access an OAUTH2/OIDC protected endpoint, but the Response contains the output on the OAUTH Token request, instead of the protected API endpoint (which is never called despite a successful oauth):

The {{oidc_issuer}}/me (userinfo) endpoint is never called, the output is from the successfull call to /token

This is what insomnia returns for the exact same configuration

Not sure if it's a mistake on my side or something different from my expectations.

Thanks

[guilhermeferrari]

+1

[diogenesc]

Facing the same issue here

[wmlele]

Just a follow up on this. Of course you can use bruno for an oauth/oidc protected api endpoint.
Just define an empty request with oauth2 authentication, and store the access_token as a variable, then just do a bearer token auth on the actual APIs using the stored access_token.
Not sure though this is the way it was intended?

[diogenesc]

Just a follow up on this. Of course you can use bruno for an oauth/oidc protected api endpoint. Just define an empty request with oauth2 authentication, and store the access_token as a variable, then just do a bearer token auth on the actual APIs using the stored access_token. Not sure though this is the way it was intended?

Probably not, seems wrong if we think how others API clients works.

[ryanholden8]

Any update on this? Seems this is a confirmed bug based on all the referencing from #2148?

[diogenesc]

+1

[deinspanjer]

I'm really excited with the potential of Bruno here but I'm running into the same issue.
If I try to set up Oauth2 as the auth directly in a request, the actual request doesn't go through, only the token issuing request.

If I try to set up Oauth2 at the collection level, and set a request to inherit, I see the note:
Note: You need to use scripting to set the access token in the request headers.

But I'm not sure how exactly to do that.
Does the Collection's oauth get automatically called first?
Where is the access token from the collection stored so I can do something with it?

[lord-haffi]

+1
Currently I'm using this workaround (for anybody who didn't find it): #1704 (comment)

[markwimpory]

this seems a bit mad. BIG oneup from me...

[alexandre-ava]

+1 Currently I'm using this workaround (for anybody who didn't find it): #1704 (comment)

Workaround works fine (thank you for posting it) but I hope it will be corrected soon as most users will expect the OAuth feature to work out the box without having to set a post script and manually setting the header.

[dbellingroth-eepos]

+1 I just had a meeting with a colleague and this was the issue that prevented him from using bruno. I try to advocate for bruno in my team but with this level of oauth support it's hardly usable for them.

[AldaCL]

• 1
  I'm currently experimenting the same issue. scripted Bearer Auth as workaround works just fine, but it becomes stressfull when trying to test multiple endpoints/users.

I'll try to add some PR in the next weekends 🤓, just need to read the contrib manual.

It seems like an important fix/feature for the project to be adopted in my team 😢

[apischan]

the same here. I would really like to use bruno because it is lightweight so far but due to this issue I cannot. unfortunately..

Fun fact that in Timeline it shows that it hits the request to the endpoint which it have to hit (specified in request string) but in fact it shows the response from OAuth2 token provider.

[mgross-ebner]

Same here, would love to adopt bruno but with this kind of oauth2 integration, it's not possible

[austeny]

Similar to many who commented prior. Its difficult to recommend using Bruno as a tool without this feature working properly. Is this on a the radar of the Bruno team since it does seem like a big detractor from people adopting the tool

[timozn]

OAuth interface improvements is a priority for us in Sep 2024. I will share more updates on this soon.
#2077 (comment)

So it is on their radar, however I think the timeline is a bit off.

[daniel-huser]

Very weird issue. Made me look for user errors for 30min until I found this here.

[khru]

Same Issue here

[Metamogul]

+1

[Kronopt]

I'm having the same issue on Bruno 1.35.0 (latest as of this writing).

I have a request with Auth configured with OAuth 2.0 and Grant Type Password Credentials. The response I get is the call to the auth endpoint instead of the actual request endpoint

[apischan]

Guys, please react with 👍 for the issue. There are 63 messages already but only 32 votes. I think that could promote this issue.

[jordyc2163]

Following up on @wmlele 's comment, a workaround is to set an empty environment variable access-token in your configuration. At the collection level, under scripts, you can input this script to populate that env variable:

pre request

if (!req.req.oauth2) {
  req.setHeader("Authorization", bru.getEnvVar("access-token")) 
}

post response

try {
  if (res.getBody().access_token) {
    bru.setEnvVar("access-token", res.getBody().access_token);
  }  
} catch (err) {
  console.log(err)
}

then generate an Oauth2 token and save it
Note that you can leave the auth in the actual request level to NoAuth and it will work

[carloshenriquefbf]

Following up on @jordyc2163's comment, you need to add the token on the Body of the request (authorization header) most (if not all) of the time.

However how to deal with expired tokens? Having to go back to the collection, getting the access token, then going back to the endpoint to test every x minutes is a hassle.

On insomnia it'd just call "get access token" before making the request if it had expired.