3 ms·

We use Google OAuth to handle hundreds of registrations each day and haven't encountered this before. No errors, no customer reports. Following your instruction

by shrink 2y ago

We use Google OAuth to handle hundreds of registrations each day and haven't encountered this before. No errors, no customer reports. Following your instructions, I logged in to my own Google account, removed the connection to our app (via "Third-party apps & services") and then did the login again: after clicking "continue" the screen changes to "loading" instantly before redirecting after a few seconds. There's no ability to click "continue" twice. I then tried to sign up to your app following your instructions and I can reproduce the issue there: the screen doesn't change to "loading" view that I get for our app. Can you share a copy of your OAuth consent screen settings? Maybe there's an option influencing this behaviour. edit: we do not use Auth0, our Google OAuth connection is built in house. edit edit: comparing the URLs, our flow redirects from `https://accounts.google.com/signin/oauth/id https://accounts.google.com/signin/oauth/id` to `https://accounts.google.com/signin/oauth/consent https://accounts.google.com/signin/oauth/consent` after clicking "continue" whereas yours remains on `https://accounts.google.com/signin/oauth/id https://accounts.google.com/signin/oauth/id` before redirecting to your app so there's definitely something different in the behaviour.

Aalk4308 2y ago
Interesting! It's certainly possible there are additional factors at play beyond what I've found to this point. Curiously, in all other apps I tested and mentioned, I don't see the screen changing to "loading" on them. Do you? Meantime, I'm checking the OAuth consent screen settings to see if there's anything relevant.
- shrink 2y ago
  According to Google Cloud, our App was created in 2018. ChatGPT, Retool, Ramp, PostHog and HubSpot have the behaviour you've described. I checked my browser history for `oauth/consent` and found the following examples with the loading behaviour: HelpScout, Google Cloud, Termly.io
  - Aalk4308 2y ago
    Very interesting. I just tried in Termly.io as well, and I do see the loading indicator you mentioned, albeit not _immediately_ (if I throttle the network speed, there is a delay before it appears). I captured a HAR file and am inspecting it to see if it has anything revealing about why the loading screen appears in some cases but not others.
- shrink 2y ago
  After watching network requests, I think it's based on the use of the Javascript login functionality vs. the redirect functionality. If the "Login with Google" button opens in a new tab and the Google OAuth flow completes in the second tab, then the process will have the "loading" screen after clicking "continue" because "loading" indicates Google OAuth is communicating back to the original tab. If the "Login with Google" button opens in the same tab, clicking "continue" triggers a 302 redirect to your callback URL of which the loading speed is controlled by your website. The immediate workaround is to switch to opening the Google OAuth login page in a new window. edit: "Sign In with Google for Web" appears to be what provides the new tab for login functionality https://developers.google.com/identity/gsi/web/guides/overview https://developers.google.com/identity/gsi/web/guides/overvi... edit edit: that's not to say you're wrong, Google should definitely fix this but "Sign In with Google for Web" is not impacted in case anyone needs an immediate fix for their own apps, they can switch to "Sign In with Google for Web" (a difference user interface for OAuth).
  - modeless 2y ago
    The problem with this is it doesn't support OAuth scopes. So if you need any Google account permissions beyond a simple sign in you can't use it.
mritchie712 2y ago
maybe if you throttle your network (e.g. "low end mobile") you can hit it?
Aalk4308 2y ago
Agreed that there's definitely something different in the behavior. I looked through the HAR files I've captured comparing my company's app to Termly. After clicking "Continue", in both cases there's a redirect to a URL of the form https://accounts.google.com/signin/oauth/consent?as=redacted&authuser=redacted&client_id=redacted&flowName=GeneralOAuthFlow&part=redacted&rapt=redacted https://accounts.google.com/signin/oauth/consent?as=redacted.... For my company's app, hitting that URL results in another redirect to my Auth0 tenant, whereas for Termly, hitting that URL results in HTML showing the loading indicator (no immediate redirect). Why the difference? As you said, maybe it's something in the OAuth consent screen configuration (though there are no options I see that could explain it). Maybe it has to do with the age of the account.

by shrink 2y ago

Aalk4308 2y ago

Interesting! It's certainly possible there are additional factors at play beyond what I've found to this point. Curiously, in all other apps I tested and mentioned, I don't see the screen changing to "loading" on them. Do you? Meantime, I'm checking the OAuth consent screen settings to see if there's anything relevant.

shrink 2y ago
According to Google Cloud, our App was created in 2018. ChatGPT, Retool, Ramp, PostHog and HubSpot have the behaviour you've described. I checked my browser history for `oauth/consent` and found the following examples with the loading behaviour: HelpScout, Google Cloud, Termly.io
- Aalk4308 2y ago
  Very interesting. I just tried in Termly.io as well, and I do see the loading indicator you mentioned, albeit not _immediately_ (if I throttle the network speed, there is a delay before it appears). I captured a HAR file and am inspecting it to see if it has anything revealing about why the loading screen appears in some cases but not others.
shrink 2y ago
After watching network requests, I think it's based on the use of the Javascript login functionality vs. the redirect functionality. If the "Login with Google" button opens in a new tab and the Google OAuth flow completes in the second tab, then the process will have the "loading" screen after clicking "continue" because "loading" indicates Google OAuth is communicating back to the original tab. If the "Login with Google" button opens in the same tab, clicking "continue" triggers a 302 redirect to your callback URL of which the loading speed is controlled by your website. The immediate workaround is to switch to opening the Google OAuth login page in a new window. edit: "Sign In with Google for Web" appears to be what provides the new tab for login functionality https://developers.google.com/identity/gsi/web/guides/overview https://developers.google.com/identity/gsi/web/guides/overvi... edit edit: that's not to say you're wrong, Google should definitely fix this but "Sign In with Google for Web" is not impacted in case anyone needs an immediate fix for their own apps, they can switch to "Sign In with Google for Web" (a difference user interface for OAuth).
- modeless 2y ago
  The problem with this is it doesn't support OAuth scopes. So if you need any Google account permissions beyond a simple sign in you can't use it.

mritchie712 2y ago

maybe if you throttle your network (e.g. "low end mobile") you can hit it?

Aalk4308 2y ago

Agreed that there's definitely something different in the behavior. I looked through the HAR files I've captured comparing my company's app to Termly. After clicking "Continue", in both cases there's a redirect to a URL of the form https://accounts.google.com/signin/oauth/consent?as=redacted&authuser=redacted&client_id=redacted&flowName=GeneralOAuthFlow&part=redacted&rapt=redacted https://accounts.google.com/signin/oauth/consent?as=redacted.... For my company's app, hitting that URL results in another redirect to my Auth0 tenant, whereas for Termly, hitting that URL results in HTML showing the loading indicator (no immediate redirect). Why the difference? As you said, maybe it's something in the OAuth consent screen configuration (though there are no options I see that could explain it). Maybe it has to do with the age of the account.