After GitLab 18.x upgrade (Omnibus), omniauth-oauth2-generic fails – id_path broken

Description

• Environment: GitLab Omnibus, using omniauth-oauth2-generic strategy.

• In 17.x (including fresh Omnibus installs), login works fine.

• After upgrading to 18.x, login fails:

  • email / name must be lowercase to work.

  • id_path (e.g. "UserId") no longer retrieves value.

• /userinfo response from provider is unchanged and valid.

Config (simplified):

user_response_structure: {
  root_path: [],
  id_path: ["UserId"],
  attributes: { email: "Email", name: "Name" }
}

Question

Did 18.x or omniauth-oauth2-generic change how user_response_structure handles keys (case sensitivity / id_path)? Any known workaround for Omnibus installations?

I recommend to check documentation about what you are using. Version 18.0 deprecated a lot of things a there are some “breaking changes” to check.

I use this tool before running any upgrade to check for changes between versions. This link shows about upgrading from 17.11 to 18.0 I think, but you can refine your versions, and then click on “Deprecations” red button.

I hope this helps.

Thank you for your suggestion! I’ve gone through the breaking changes page, but I couldn’t identify anything that seems directly related to this issue.

Just to clarify my testing steps:

1. Installed a fresh 17.11.7 Omnibus instance.

2. Configured omniauth-oauth2-generic, login worked fine.

3. Upgraded directly to 18.2.4 following the upgrade path.

4. Tested login again → failed with 422 Email is blank.

5. Updated config to use lowercase for email, name, and id_path.

6. Tested login again → login succeeded, but the user’s unique identifier remains empty (it seems id_path is not being resolved).

I’m wondering if this is a regression in 18.x or if there’s a recommended workaround for handling id_path with Omnibus installations using omniauth-oauth2-generic. Any guidance would be greatly appreciated.

Try changing to user_id.

We have noted when the user_info endpoint is called, Gitlab 18+ is now converting camelCase to snake_case after the data is fetched from the userinfo endpoint.

For example, if you previously mapped email → primaryEmail, you need to change that to: email → primary_email.

I followed your instructions, and it’s working perfectly on GitLab 18.4.1.
Thank you very much for your help — you really saved my day

You are very welcome.
Happy it worked out for you.