Allow for resetting/invalidating the current OAuth2 stored token

[andraz-kozelj]

I have checked the following:

• [x] I have searched existing issues and found nothing related to my issue.

This bug is:

• [ ] making Bruno unusable for me
• [x] slowing me down but I'm able to continue working
• [ ] annoying
• [ ] this feature was working in a previous version but is broken in the current release.

Bruno version

2.3.0

Operating System

macOS 15.5

Describe the bug

I have a collection with the OAuth2 setup, working fine - when clicking "Get token" I can successfully obtain the token and the API request relying on it works fine.

But as I'm developing other features, also relying on the token content, I need to be able to reset the content programmatically, i.e. bru.resetOauth2Token('sandbox_portal') or similar, passing the Token ID.

If this is used in the collection script pre-request, it should trigger a new OAuth2 cycle to obtain a new token.

As an extra, getting access to this token for any further API usage would also be useful, i.e. bru.getOauth2Token('sandbox_portal')

console.log(bru.getVar('$oauth2.sandbox_portal.access_token')) does not work, as the variable name contains an invalid character.

.bru file to reproduce the bug

No response

Screenshots/Live demo link

[anusree-bruno]

This makes sense, we will see how we can do this. One thing to consider here is that multiple OAuth2 requests can have same credentialID hence resetting this will probably reset all these requests.

But for the second part we do provide oauth2 token access in scripts you can do

bru.getOauth2CredentialVar(`$oauth2.credentials.access_token`)

https://docs.usebruno.com/auth/oauth2-2.0/overview#accessing-oauth2-tokens-in-scripts

[andraz-kozelj]

Great, thanks, missed the latter script function in the docs!

[juulderuysscher]

@anusree-bruno I have a similar use case where I would require more possibilities then the current

bru.getOauth2CredentialVar(`$oauth2.credentials.access_token`)

I have an API which accepts tokens from multiple OAuth 2.0 resource servers. Currently I don't have an other way then creating some dummy folders with an OAuth 2.0 configuration and a separate Token ID. Based on the environment I then can pass the correct access token from the getOauth2CredentialVar function. However I will have to manually go to this folder to initialize a new token or to refresh it when expired.

My workflow could be further automated if I was able to automatically initialize the token if it is not available. I would expect the following methods to be available in the JavaScript API of Bruno:

bru.createOauth2Token(`$oauth2.credentials.access_token`)
bru.refreshOauth2Token(`$oauth2.credentials.access_token`)
bru.clearOauth2CredentialCache(`$oauth2.credentials.access_token`)

These methods would enable users to fully automate OAuth 2.0 flows in complex environments.

[anusree-bruno]

Wouldnt enabling auto fetch token and auto refresh token solve the first two use cases?

[juulderuysscher]

@anusree-bruno thank you for the quick response. I had these two checkboxes checked already. So I would indeed have expected that it would have been handled out of the box by the existing method.

[anusree-bruno]

Ah, makes sense now! You’re saying the refresh/refetch needs to happen after switching environments. I missed that part.

[giuseppemilicia]

@anusree-bruno My use case is a bit different, I need to obtain a new token every time I request a new login, because the token is only valid for a few seconds after it's created

[anusree-bruno]

@giuseppemilicia

As @juulderuysscher suggested, having these apis will enable you to validate the token and refetch it via script

bru.createOauth2Token(`$oauth2.credentials.access_token`)
bru.refreshOauth2Token(`$oauth2.credentials.access_token`)
bru.clearOauth2CredentialCache(`$oauth2.credentials.access_token`)

Or would you suggest having this as an OAuth2 config setting to refetch the token on every call?

[giuseppemilicia]

@anusree-bruno i'm wondering if it's possible to invoke clearOAuth2CredentialCache in the pre-request script. That would be ideal, but I'm not sure how it's implemented in the lifecycle. If the OAuth2 flow is triggered before the pre-request script runs, then this approach wouldn't work. In that case, I believe a configuration setting would be a simpler and more reliable solution