invalid_origin error in OpenID Connect flow with Google after enabling self-service registration

[eirikur-grid]

invalid_origin errors start occurring after self-service registration is enabled

Description

We have configured a OpenID Connect Identity Provider for Google. We choose this option over the built-in Google provider as it causes a pop-up window to open. This has been working fine for us. However, after having enabled self-service registration on our staging environment we started noticing errors, with users redirected to our authorization page with the following querystring arguments:
?error=invalid_request&error_reason=invalid_origin&error_description=Invalid+origin+uri+https%3A%2F%2Faccounts.google.com%2F...

At first, we modified our Application in FA, adding https://accounts.google.com to the list of authorized request origin URLs. Later, we found that when logging in with our @grid.is Google accounts in a freshly opened Incognito window, we'd be redirected to https://accounts.google.is (notice the .is top-level-domain) during the authentication flow and get the same error, unless we also add https://accounts.google.is to the list. I have tried adding https://accounts.google.* to the list but that doesn't appear to work. I therefore see only two options:

a) Empty out the list of authorized request origin URLs to allow all
b) Manually add an entry for every top-level-domain that Google has

I'm not particularly fond of either. Is there anything else we can do?

Below is a screen capture of an authentication flow that ends with an error. If you pay attention to the address bar, you'll notice a brief visit to https://accounts.google.is/accounts/SetSID right before the user is redirected back to us.

[robotdan]

Questions:

1. Prior to 1.21.0, were you using the authorized origin configuration, if so, what was the configuration. If not, then I assume you only started adding origin values after the upgrade?
2. Are you using a theme, it looks like you are.
3. Do you have self service registration enabled?

It may also be helpful to see a HAR file of the sequence you recorded to see which redirects are occurring in order.

I was able to set up our Google account as an OIDC provider and it worked fine.

It sounds like the HTTP origin header is changing based upon the user's locale, or maybe even the browser or browser mode (incognito). If you are configured to validate the origin, then it seems like you would just have to configure each possible origin.

I don't see anything that is jumping out at me as far as changes in this validation.

[eirikur-grid]

Answers:

1. Yes. We had 13 URLs listed, some used for the actual authentication flow on our staging environment, others for various development projects.
2. Yes
3. Ah...that's interesting. We are currently working on streamlining our sign-up flow so we have self-registration enabled on our staging environment but not the production environment.

[robotdan]

Ok, for fun - can you try disabling self service in stage and see if that removes the symptom? This may give us a clue as to what may be causing the change.

[eirikur-grid]

Confirmed, with self-service registration disabled I can no longer reproduce the issue.

[eirikur-grid]

I'll update the title and description of the issue in light of this being related to self-service registration, and not the version upgrade.

[robotdan]

Ok, good to know.

I am unable to recreate so far, I tried with a normal configuration, and then also with self service registration enabled.

Can you also attempt to recreate with self service enabled using the stock (default) theme, this will tell us if we have a problem in general, or something is different in your themed template than the default one that may be causing the issue.

[eirikur-grid]

I've tried with the default theme but I still get the invalid_origin error.

[robotdan]

Ok, so the work around is to do one of two things:

1. Remove all Authorized Origins
2. Add all possible TLDs for the https://accounts.google.* origin to the authorized origin configuration.

I'll have to dig into that path to see what would be different. More to come.

[eirikur-grid]

Here's the OpenID connect configuration, if that helps

[robotdan]

So far I've been unable to recreate.

In your screenshot/gif I see a few redirects after you log into Google, please outline the entire flow with each redirect or provide a HAR file of the recreate so I can ensure we are testing the same workflow.

Thanks!

[robotdan]

I think I figured it out.

Note: Cannot reproduce in Brave, but I can reproduce in Chrome. This is because Brave is omitting the Referer header which is used as a fall back for the Origin header when trying to validate the origin.

Here is what is happening:

Works: Self Service Registration Enabled : false

1. Click Login with Google
2. FusionAuth redirects to Google, you login, and a 302 redirect occurs to /oauth2/callback
3. FusionAuth validates this request, but skips Origin validation because it is a callback we initiated.
4. We login, redirect to /oauth2/authorize and then complete the login by redirecting to the requested redirect_uri.

Does not work: Self Service Registration Enabled : true

1. Click Login with Google
2. FusionAuth redirects to Google, you login, and a 302 redirect occurs to /oauth2/callback
3. FusionAuth validates this request, but skips Origin validation because it is a callback we initiated.
4. We login, redirect to /oauth2/authorize and then redirect to /oauth2/complete-registration to process any necessary registration detail.
5. The 302 redirect to /oauth2/complete-registration by FusionAuth then validates the origin.
6. Because this is a redirect chain initiated by a GET there is no Origin header, and instead we fall back to the Referer which is https://accounts.google.is (in this case) - this value is not configured as an allowed origin and we fail.

So, technically the failure is correct - this origin is not registered and thus we cannot validate it. However - perhaps we are being a bit too aggressive here - the Origin validation which is optional - likely should only be verified when it is an unsolicited request and the user has not yet completed authentication. This means we should validate the origin (if configured) on requests to /oauth2/authorize and /oauth2/register and perhaps a couple of others. But - once we start performing redirects to third parties, and ourselves and the user has been authenticated but we are justing completing a workflow, we likely do not need to validate the origin any longer.

The plan is to re-work when we perform origin validation so that this validation behavior does not change based upon the self service configuration setting.

Also - as a side note, validating the origin is not that important in my opinion. Unless you're in a legit browser, modifying or removing this header is not out of the question, and if the header is omitted we cannot validate the origin. So this validation can be bypassed relatively easily. This is why I was originally unable to recreate using Brave, it had removed the header so the Origin configuration was not being used.

The one current use case where this configuration is valuable, is if you need to load any of the themed pages in an IFRAME, in this case we use the Authorized Origin configuration to know when to omit the X-Frame-Options: DENY.

[eirikur-grid]

Thanks for the detailed write-up.

[glen-84]

@robotdan

Was this ever fully resolved?

I'm seeing the following in error logs, and I'm assuming it's the same issue:

Do we have to add each of these URLs as valid origins to each application? Is it safe to just not use authorized request origin URLs at all?