Oauth2 browser

frontline · January 14

Is it possible to define which browser is used, or even better use our builtin browser (TMSFNCWebrowser which is built on MSWebView)?

We have some environments that are heavily locked down and my tech team is justifiably worried about letting users have unfettered access to a browser.

If we can use our builtin browser with much greater control, but still rely on the great infrastructure of ReportBuilder to handle the majority of the flow, it would be the best of both worlds.

We saw a few properties related to Builtin browsers under ConnectionSettings, but setting to True didn't seem to do anything though im sure there'd be more to it we're missing.

nicocizik · January 14

Hi Dusten,

As various REST OAuth2 services have matured, they have become more and more picky about what they allow. Initially, services such as Google and Microsoft allowed OAuth2 authentication from an embedded browser such as TWebBrowser or TEdgeBrowser. Unfortunately now this has been taken away and authentication must be done in a stand-alone browser (generally the default browser on the machine).

This supposedly provides more security because the host application has no control over the browser and therefore cannot obtain the users' credentials.

ReportBuilder now creates a "loopback" server that listens to a specific port for authentication information once the user logs in from their default browser. This is currently the standard way for desktop applications to work with OAuth2.

If your browser was a stand-alone application, it could be possible to use that for authentication if it were assigned the default browser of the machine.

frontline · January 14

I see, understood.

Let me share another idea they threw out to verify it would work before we go for it.

We install a local application that just sends a dummy email. They go through the OAuth flow and all is good. We export their registry setting with the AccessToken, Expiry, and RefreshToken. We import that into their strict environment.

From here could they email within the strict environment? What would happen when the keys start to expire?

nicocizik · January 15

Hi Dusten,

>>From here could they email within the strict environment?

Correct.

>>What would happen when the keys start to expire?

Users would need to log-in again with the initial local application to obtain a valid access token and refresh token.

Access tokens are valid for 1 hour. Once an access token expires, the refresh token is used (if valid) to obtain another Access Token for another hour of access.

The expiration of refresh tokens varies and is always changing. Google claims their refresh tokens are valid indefinitely until revoked. Microsoft recently changed their policy to only allow 90 days.

Oauth2 browser

Comments