usebruno
Use system browser for OAuth authentification
I have checked the following:
- [X] I've searched existing issues and found nothing related to my issue.
Describe the feature you want to add
For Oauth2 authentifiction, (and for others eventually), when clicking on "Get Access Token", the system's browser should be opened (not the bruno integrated one). Why that? It will allow users to have access to theirs password managers configured on theirs browser. It's a cool feature that make life easier.
Mockups or Images of the feature
See as postman is working.
This issue blocks my usage of Bruno on my system. My organisations authorisation does not allow the Electron browser to be used.
This issue blocks my usage of Bruno on my system. My organisations authorisation does not allow the Electron browser to be used.
+1 Due to this issue, we are not able to use Bruno at my organization. @helloanoop Please help here.
My thoughs: this request is not impossible, but may still be not ideal in the environments where the organization has very strict requirements about software you use. The oauth2 browser flow would start with bruno executing shell request to open Authorization URL. It would normally be a https request, and it would be handled by the default browser loading the login page. First potential, albeit minor problems here are:
- It is very likely that the browser silently switches from http to https, which may result in login page being unreachable. Agreed, you should not host your auth server without TLS, but just pointing that as a potential problem outside of what Bruno can help with.
- Untrusted TLS - Bruno's settings for custom CA or disabling TLS verification will not work in the browser. We must assume it is configured correctly.
The more important problem is the core of how OAuth2 works: after the successful authorization the browser is supposed to redirect to the Callback URL. This redirect carries credentials that we are interested in, but they must somehow return back to Bruno. Currently, as Bruno is handling the browsers function, it simply extracts the credentials and ignores the redirect uri completely, but the browser will not do that. This creates another set of problems:
- Can I redirect to Bruno?
- How to redirect to Bruno?
The first question is about whether the authorization server allows arbitrary callback urls. If not - the url to Bruno must be explicitly whitelisted in the server configuration. This in itself may be considered security violation, depending on the type of application, or the user may simply not have that kind of access, in which case it's game over.
The second question is a main technical challenge for Bruno developers. From what I understand electron applications may be registered as custom protocol clients, and in fact Bruno does register itself as a client for bruno:// protocol. That means the browser redirecting to bruno://xxx would launch another instance of Bruno, and it would be able to consume the callback url with credentials included. For this to make sense however, Bruno must be launched as a single instance application, because a new instance would not know what to do with the information. Also, I can only imagine that making Bruno a single instance app breaks someone's workflow. Maybe @helloanoop has his mind made up on this issue?
And of course, your desktop security policy must not be too strict for that either - if you are not able to register custom protocol clients, it's game over again. Then again, since Postman gets away with just that, it can't be a real world problem.
This issue blocks my usage of Bruno on my system. My organisations authorisation does not allow the Electron browser to be used.
I +1 this. The internal browser used doesn't send the device identifier to e.g. microsoft. With that there are restrictions that a login isn't possible to specific accounts.
It's also the only thing holding me back to buy and use bruno and to recommend it to the whole company.
+1 on this. Same reasons as most people above: a nice to have in order to use password managers, but also because the organiation policy doesn't allow me to login using the embedded browser.
This has been a pain in our organization as well where we require users use a company provided password manager and MFA everywhere. Would love to see this implemented so we can continue to expand our Bruno usage.
I have no idea what exactly is the reason, but our company login server does some strange redirects that don't work in the integrated browser. We had the same issue in Postman, but there is a "Authorize using browser" option which enables using the standard browser. I would really like to have a similar option in Bruno, otherwise I can't use it at the moment.
+1 @kbublitz I have the very same issue in our corporate environment. Also Microsoft, also missing device identifier, and on top of that we have federated login via EntraID if you come from the internal network. All those redirects stop with a 401, as soon as the kerberos flow kicks in for "interaction-less" logon. I will also open a bug ticket and reference this one here...
If you perform the very same logon flow from the internet it works with MFA.
Any news on this one? It slows down the adoption of Bruno in my org just because of that tiny issue.
It is very likely that the browser silently switches from http to https, which may result in login page being unreachable. Untrusted TLS - Bruno's settings for custom CA or disabling TLS verification will not work in the browser. We must assume it is configured correctly.
as long as builtin browser remains an option i don't see why this is a problem
The more important problem is the core of how OAuth2 works: after the successful authorization the browser is supposed to redirect to the Callback URL. This redirect carries credentials that we are interested in, but they must somehow return back to Bruno. Currently, as Bruno is handling the browsers function, it simply extracts the credentials and ignores the redirect uri completely, but the browser will not do that. This creates another set of problems:
- Can I redirect to Bruno?
- How to redirect to Bruno?
The first question is about whether the authorization server allows arbitrary callback urls. If not - the url to Bruno must be explicitly whitelisted in the server configuration. This in itself may be considered security violation, depending on the type of application, or the user may simply not have that kind of access, in which case it's game over.
The second question is a main technical challenge for Bruno developers. From what I understand electron applications may be registered as custom protocol clients, and in fact Bruno does register itself as a client for
bruno://protocol. That means the browser redirecting tobruno://xxxwould launch another instance of Bruno, and it would be able to consume the callback url with credentials included. For this to make sense however, Bruno must be launched as a single instance application, because a new instance would not know what to do with the information. Also, I can only imagine that making Bruno a single instance app breaks someone's workflow. Maybe @helloanoop has his mind made up on this issue?And of course, your desktop security policy must not be too strict for that either - if you are not able to register custom protocol clients, it's game over again. Then again, since Postman gets away with just that, it can't be a real world problem.
what about localhost on a port opened by the instance requesting authorization? i don't think adding localhost to an oauth whitelist would be controversial, and it would remove the need to make bruno single instance
what about localhost on a port opened by the instance requesting authorization? i don't think adding localhost to an oauth whitelist would be controversial, and it would remove the need to make bruno single instance
It is an option, I guess. With the caveats: the port must be preconfigurable, because the user must have the chance to whitelist the domain (of which the port is a part) in the provider configuration. Also note, in strictly regulated environments where IT Security controls your firewall, the capability to start an HTTP server may be an even harder bargain than registering a custom protocol.
Looking forward to it! I'm using Bruno for quite some time. Now I have an auth code flow API which requires me to log on to our Entra ID IdP - doesn't work with the builtin-browser. The company requires Edge browser based logins..
We have allocated time to work on this this month.
@anusree-bruno - this still doesn't redirect to MS Edge. I am using Bruno 2.10.1
My organization does not allow logins from the Bruno-integrated browser. This issue blocks me from using Bruno on internal APIs that require OAuth2.0. I need to be able to use the system browser when authenticating.
+1 Running into the same issue as mentioned above, cannot login due to company compliance policies.
This effectively makes Bruno unusable for me, unfortunately.
My organization does not allow logins from the Bruno-integrated browser. This issue blocks our users from using Bruno. Our users need to be able to use the system browser when authenticating.
@igramul, we have started working on this feature, and it is expected to be released in December
Hi everyone, quick update here. This is how we are planning to build System Browser support for OAuth 2.0.
The token requests will work exactly the same as today up until the authorization server redirects back to the callback URL. However, since Bruno is a desktop app, the system browser cannot directly “hand” the authorization code back to the app the way the inbuilt (Electron) browser can. To complete the OAuth flow securely, Bruno needs a way to receive that final callback locally.
We are planning to maintain a static page (something like https://oauth2.usebruno.com) which will immediately redirect to Bruno custom URL ( bruno://app/oauth2/callback). The app then validates the state parameter and performs the authorization-code + PKCE token exchange directly - no data is processed or stored by us.
For this to work, the user would have to add the URL (https://oauth2.usebruno.com) to the valid redirect URLs list in their OAuth 2.0 provider.
Here is the static HTML code we’ll be using to handle the local callback: https://gist.github.com/sreelakshmi-bruno/5b66224b33492a69c071379ca44eada6
Would love to get your feedback and thoughts on this. Thanks!
There are many ways to achieve that. The idea is that it will be UP TO THE USER to choose the redirect URL, which can be wither:
- localhost --> Bruno will just listen on a port on localhost to receive the code
- a custom URL scheme / protocol handler --> in this case it must be registered locally in such a way that it triggers the opening of the Bruno app
The USER must choose the appropriate redirect URL depending on the configuration of its IdP.
Regards,
Luca
Da: sreelakshmi-bruno @.> Inviato: giovedì 4 dicembre 2025 15:04 A: usebruno/bruno @.> Cc: Comment @.***> Oggetto: Re: [usebruno/bruno] Use system browser for OAuth authentification (Issue #2650)
Hi everyone, quick update here. This is how we are planning to build System Browser support for OAuth 2.0.
The token requests will work exactly the same as today up until the authorization server redirects back to the callback URL. However, since Bruno is a desktop app, the system browser cannot directly "hand" the authorization code back to the app the way the inbuilt (Electron) browser can. To complete the OAuth flow securely, Bruno needs a way to receive that final callback locally.
We are planning to maintain a static page (something like https://oauth2.usebruno.comhttps://oauth2.usebruno.com/) which then immediately redirects to Bruno custom URL ( bruno://app/oauth2/callback). The app then validates the state parameter and performs the authorization-code + PKCE token exchange directly - no data is processed or stored by us.
Here is the static HTML code we'll be using to handle the local callback: https://gist.github.com/sreelakshmi-bruno/5b66224b33492a69c071379ca44eada6
Would love to get your feedback and thoughts on this. Thanks!
Reply to this email directly, view it on GitHubhttps://github.com/usebruno/bruno/issues/2650#issuecomment-3612417289 or unsubscribehttps://github.com/notifications/unsubscribe-auth/AUJ2RTBITG6KB7SR4ZKPNW34AA5LZBFHORZGSZ3HMVZKMY3SMVQXIZNMON2WE2TFMN2F65DZOBS2YSLTON2WKQ3PNVWWK3TUUZ2G64DJMNZZFAVEOR4XAZNKOJSXA33TNF2G64TZUV3GC3DVMWUTKNBSGI4DIMZYGCBKI5DZOBS2K2LTON2WLJLWMFWHKZNKGI2DCMJQHAZDCMZXVJQXI5DSNFRHK5DFOONIFJLWMFWHKZNEORZHKZNENZQW2ZN3ORUHEZLBMRPXAYLSORUWG2LQMFXHIX3BMN2GS5TJOR4YFJLWMFWHKZNEORZHKZNENZQW2ZNOO5QXIY3IL5QWG5DJOZUXI6MCUV3GC3DVMWSWS43TOVS2I3TBNVS2W5DIOJSWCZC7OR4XAZMCUV3GC3DVMWUTCOBWGU2DEMJUGKSG4YLNMWUGCY3UN5ZF62LEQKSXMYLMOVS2UNBVHA2DMNJYGY4TFJDOMFWWLKLIMFZV63DBMJSWZAVFOZQWY5LFVI3TKOJXGE2DAMRXGOSG4YLNMWUWQYLTL5WGCYTFNSBKK5TBNR2WLKRXGU4TOMJYHE3DSNFENZQW2ZNJNBQXGX3MMFRGK3ECUV3GC3DVMWVDONRRGIYDEMRRGI22I3TBNVS2S2DBONPWYYLCMVWIFJLWMFWHKZNKG43TOMZUGY2DOMBQURXGC3LFVFUGC427NRQWEZLMQKSXMYLMOVS2UOBZGI3TGNRUGI4TJJDOMFWWLKLIMFZV63DBMJSWY. You are receiving this email because you commented on the thread.
Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
We are planning to maintain a static page (something like https://oauth2.usebruno.comhttps://oauth2.usebruno.com/) which then immediately redirects to Bruno custom URL ( bruno://app/oauth2/callback).
For this to work, the user would have to add the URL (https://oauth2.usebruno.com/) to the valid redirect URLs in their OAuth 2.0 provider.
I think this is the right way to go, but I'd like you guys to implement it in a way that does NOT hardcode the static page url - so even when using system browser, I can still provide callback url of my choosing.
If my OAuth2 provider allows me to register redirect uri that is not https (e.g. bruno://app/oauth2/callback) - I will do it, and then the authorization server itself will redirect the request the same way your static page would do. Or I may have the means to self-host such redirector on my own trusted domain. Of course having a publicly accessible standard url running on https is a good thing, great default, but not make it the only way.
Also, as a primarily flatpak user, I hope the custom protocol handler registration required for this to work will be included on day one ;).
I agree with @pietrygamat. Make it configurable but provide a public facing default url would be very nice.