Slow response in browser-authorization process

[PeterJBassett]

Hello I work on developing the FutureOn connector to iTwin used by Shell for their Bentley Plantsight projects.

I have upgraded my application to use the browser-authorization module for user sign-in.
See https://github.com/iTwin/auth-clients/tree/main/packages/browser#readme

The following problems are occuring:

1. The response to calling signInSilent can be very slow, it often takes about 20 seconds to respond.
2. Sometimes when calling signInSilent it doesn't realise that the user is already signed in, so (after the 20 seconds), it pops up the sign in window, and immediately closes it again.

The code I am using is below.

    try {
      console.log('Attempting signInSilent')
      await authClient.signInSilent()
    } catch {
      console.log('Performing signIn Popup')
      await authClient.signInPopup()
      // Note: this opens a popup for the user to sign in, and then 
      // will reopen this page with the redirect URL. 
      // The onMount code above is called and invokes the handleSignInCallback
      // which should close the popup and return here.
    } 

[ben-polinsky]

Hello,

There's a chance this is related to a change made on the IMS backend. I'll take a look at let you know if there's a fix we can make on our end.

[ben-polinsky]

I'm not able to reproduce on a test viewer application. Are there any failed or slow network calls? Specifically to ims.bentley.com?

[PeterJBassett]

Hello @ben-polinsky thank you very much for your reply.
Looking in the chrome console, I can see the following logs.

It seems to be something to do with handling third-party cookies. It generates 52 of these logs during the 10s it takes to trigger the pop-up. The logs about third-party cookies are something to do with ims.bentley.com queries.

See screenshots below:

[PeterJBassett]

@ben-polinsky in the logs shown above, this is the URL string that is being logged in the 52 logs:

https://ims.bentley.com/connect/authorize?
client_id=spa-m19YIiH1EpMzsd9RYBGa9jIJL
&redirect_uri=https%3A%2F%2Fpeter-itwin-integration-frontenduser.futureon-dev.fieldtwin.com%2Fredirect
&response_type=code
&scope=email+openid+profile+organization+itwinjs+itwin-platform
&state=751b398f9ace424f8ca4998a293b1cc2
&code_challenge=4_pIypR_wVDATzkpmF39anvrgTxM4O6rLgXWSxypgGM
&code_challenge_method=S256
&response_mode=query
&prompt=none

[ben-polinsky]

Hm.. I do see these issues in my browser, yet I am not experiencing the slow responses you are seeing.

If you check the network tab in chrome devtools, is there a certain request or requests that are taking the 10 seconds?
You noted you upgraded to the browser authorization package. What were you previously using which did not produce this behavior?

I have a few ideas for trying to narrow down the issue:

1. Could you try a different browser?
2. Could you push your code (or at least the auth part) for me to test?
3. And/or try out your setup with this react template app: https://github.com/iTwin/viewer/tree/master/packages/templates/cra-template-web-viewer?

[ben-polinsky]

Update. In the case of the app built with vite, the issue was that the redirectUrl and my main app were using the same url. This probably triggered an error of some sort in the hidden iframe, or otherwise prevented the handleSigninCallback() call from completing.

Check that the redirectUrl used to initialize the client corresponds to a route that only handles the sign in callback and nothing else. With this code, the signinSilent() call toward the bottom fails immediately:

import { BrowserAuthorizationClient } from '@itwin/browser-authorization'
const redirectUri = "http://localhost:5173/signin-callback"

// ensure the redirect url does nothing else but handle the callback
if (redirectUri === window.location.pathname) {
  BrowserAuthorizationClient.handleSignInCallback().then(() => {
    console.log("handled")
  })
} else {
  // ensure the client isn't being instantiated on the redirectUri route.
  const client = new BrowserAuthorizationClient({
    redirectUri,
    scope: "itwin-platform",
    responseType: "code",
    authority: "https://ims.bentley.com",
    ...
  })

  document.querySelector<HTMLDivElement>('#app')!.innerHTML = `
    <div>
      <a href="https://bentley.com" target="_blank">
        <img src="https://www.bentley.com/wp-content/uploads/2022/04/bentley-logo-400X100-black.svg" class="logo" alt="Vite logo" />
      </a>
      <a href="https://itwinjs.org" target="_blank">
        <img src="https://pbs.twimg.com/profile_images/1050473874058563585/Fs0iAFxh_400x400.jpg" class="logo" alt="Vite logo" />
      </a>
      <h1>iTwin.js Demo App</h1>
      <div class="card">
      ${client.isAuthorized ? 'Signed in' : 'Not signed in'}
        <button id="sign-in" type="button">Sign in</button>
      </div>
    </div>
  `
  document.querySelector("#sign-in")!.addEventListener("click", async () => {
    try {
      await client.getAccessToken() // throws immediately
    } catch (error) {
      await client.signInSilent() // now fails fast and throws
    }
  })
}

Whether or not this is the underlying issue you're facing, the fact that you are hitting the timeout does indicate something is wrong with your implementation.

[PeterJBassett]

Hello @ben-polinsky thank you very much for your help.
I will try updating my app as you have suggested.

[PeterJBassett]

Hello @ben-polinsky thanks again for all your help.
I have found that if I use oidc-client-ts to log in to Bentley everything works instantly, with no delays.

  async function signIn() {
    let user
    try {
      user = await userManager.getUser()
      if (!user) {
        await userManager.signinPopup()
        // the popup calls userManager.signinPopupCallback()
        user = await userManager.getUser()
      }
      if (user) {
        console.log('Successfully signed in', user)
        signInResult.jwt = user.auth_token
        ...

Unfortunately, I realise that this does not give the right auth_token, and that @itwin/browser-authorization probably does some extra step to get the actual iModel access token. So this doesn't solve my problem. So I will stick with using @itwin/browser-authorization

The question is, why does there have to be a timeout, why cant it call oidc-client-ts userManager.getUser() to find out if the user is already signed in.

[aruniverse]

You are probably just missing the token_type which is just Bearer
The access token we expect to be used with iTwin Platform will be ${user.token_type} ${user.access_token}

[PeterJBassett]

Hello @aruniverse - yes of course that was it!!. So it now works using oidc-client-ts directly,
Thank you very much for your help.

[ben-polinsky]

I have found that if I use oidc-client-ts to log in to Bentley everything works instantly, with no delays.

Curious - which version? :) We're on 2.x. Maybe they've fixed this behavior in 3.x.

[PeterJBassett]

Hello @ben-polinsky it is version 3.1.0