Newly Created User in GitLab doesn't automatically get linked to an OAuth account with Google OAuth2 OmniAuth Provider
Summary
This is a on-premise installation of GitLab CE 11.4.5. We are strictly using Google OAuth2 OmniAuth Provider as the sole authentication method as we are using GSuite accounts. Following all the steps in https://docs.gitlab.com/ee/integration/google.html we've setup OAuth 2.0 Client ID properly and configure it on GitLab correctly and all accounts are able to use Google Accounts to sign in to GitLab no problem as long as their User Settings->Account->Social sign-in->Connected Accounts->google_oauth2 provider is linked properly.
However, a newly created account in GitLab doesn't automatically get linked to their Google OAuth2 profile upon the first OAuth sign-in, as a result, the newly created user click on the welcome email link will get to a google oauth login screen and once signed in successfully it still gets kicked back to the same oauth screen, hence a loop.
The only way we discovered to work around this is to have an admin to impersonate the newly created user and have the new user to connect his/her social account Google OAuth2 credential (in User Settings->Account->Social sign-in->Connected Accounts screen). After then, they can single sign-on properly with their google credentials.
Steps to reproduce
- Create a new user in GitLab, with names and a Google Account email.
- A welcome email from GitLab is sent to the given Google Account email, clicking on the login link to land on GitLab public page.
- Click on sign in on GitLab, get prompted an OAuth login screen, put in google credentials to authenticated.
- It immediately kicks it back the OAuth login screen again just like step 3 above. Try the valid credentials to login again
- rinse and repeat from step 3 to step 5
What is the current bug behavior?
GitLab cannot identify and automatically link/match the OAuth login credential email with the new account just created with the same email on the first time (before 2FA is setup, perhaps 2FA setup prevent that?)
What is the expected correct behavior?
For new users created inside GitLab, after they get passed their initial oauth login screen they should be logged in. (by matching their OAuth credential email and their GitLab account email), just link how the Social account link page does.
Essentially, we have to do this steps: https://docs.gitlab.com/ee/integration/omniauth.html#enable-omniauth-for-an-existing-user as a workaround in order to get out of redirect loop. But the initial sign in should link the accounts so that we don't have to do that.
Relevant logs and/or screenshots
I can't find the relevant logs but the screens are pretty standard.
Results of GitLab environment info
Expand for output related to GitLab environment info
root@gitlab:/home/git/gitlab# entrypoint.sh app:rake gitlab:env:info Loading /etc/docker-gitlab/runtime/env-defaults Initializing logdir... Initializing datadir... Updating CA certificates... Installing configuration templates... Configuring gitlab... Configuring gitlab::database Configuring gitlab::redis Configuring gitlab::secrets... Configuring gitlab::sidekiq... Configuring gitlab::gitaly... Configuring gitlab::monitoring... Configuring gitlab::gitlab-workhorse... Configuring gitlab::unicorn... Configuring gitlab::timezone... Configuring gitlab::rack_attack... Configuring gitlab::ci... Configuring gitlab::artifacts... Configuring gitlab::lfs... Configuring gitlab::uploads... Configuring gitlab::mattermost... Configuring gitlab::project_features... Configuring gitlab::smtp_settings... Configuring gitlab::incoming_email... Configuring gitlab::oauth... Configuring gitlab::oauth::google... Configuring gitlab::ldap... Configuring gitlab::cron_jobs... Configuring gitlab::backups... Configuring gitlab::registry... Configuring gitlab::pages... Configuring gitlab-shell... Configuring nginx... Configuring nginx::gitlab... Configuring nginx::gitlab::ssl... Configuring nginx::gitlab::hsts... Running raketask gitlab:env:info... Missing Rails.application.secrets.openid_connect_signing_key for production environment. The secret will be generated and stored in config/secrets.yml.System information System: Current User: git Using RVM: no Ruby Version: 2.4.4p296 Gem Version: 2.6.14.1 Bundler Version:1.17.1 Rake Version: 12.3.1 Redis Version: 3.0.6 Git Version: 2.19.1 Sidekiq Version:5.2.1 Go Version: unknown
GitLab information Version: 11.4.5 Revision: f5536c61 Directory: /home/git/gitlab DB Adapter: postgresql URL: https://gitlab.example.com HTTP Clone URL: https://gitlab.example.com/some-group/some-project.git SSH Clone URL: git@gitlab.example.com:some-group/some-project.git Using LDAP: no Using Omniauth: yes Omniauth Providers: google_oauth2
GitLab Shell Version: 8.3.3 Repository storage paths:
- default: /home/git/data/repositories Hooks: /home/git/gitlab-shell/hooks Git: /usr/bin/git
Results of GitLab application Check
Expand for output related to the GitLab application check
root@gitlab:/home/git/gitlab# entrypoint.sh app:rake gitlab:check SANITIZE=true Loading /etc/docker-gitlab/runtime/env-defaults Initializing logdir... Initializing datadir... Updating CA certificates... Installing configuration templates... Configuring gitlab... Configuring gitlab::database Configuring gitlab::redis Configuring gitlab::secrets... Configuring gitlab::sidekiq... Configuring gitlab::gitaly... Configuring gitlab::monitoring... Configuring gitlab::gitlab-workhorse... Configuring gitlab::unicorn... Configuring gitlab::timezone... Configuring gitlab::rack_attack... Configuring gitlab::ci... Configuring gitlab::artifacts... Configuring gitlab::lfs... Configuring gitlab::uploads... Configuring gitlab::mattermost... Configuring gitlab::project_features... Configuring gitlab::smtp_settings... Configuring gitlab::incoming_email... Configuring gitlab::oauth... Configuring gitlab::oauth::google... Configuring gitlab::ldap... Configuring gitlab::cron_jobs... Configuring gitlab::backups... Configuring gitlab::registry... Configuring gitlab::pages... Configuring gitlab-shell... Configuring nginx... Configuring nginx::gitlab... Configuring nginx::gitlab::ssl... Configuring nginx::gitlab::hsts... Running raketask gitlab:check... Missing Rails.application.secrets.openid_connect_signing_key for production environment. The secret will be generated and stored in config/secrets.yml. Checking GitLab Shell ...
GitLab Shell version >= 8.3.3 ? ... OK (8.3.3) Repo base directory exists? default... yes Repo storage directories are symlinks? default... no Repo paths owned by git:root, or git:git? default... yes Repo paths access is drwxrws---? default... yes hooks directories in repos are links: ... 3/1 ... ok 3/2 ... ok 3/3 ... ok 3/4 ... ok 3/5 ... ok 3/6 ... ok 3/7 ... ok 11/8 ... ok 6/9 ... repository is empty 3/10 ... ok 15/11 ... ok 3/12 ... ok 6/14 ... ok 3/16 ... ok 3/17 ... ok 3/18 ... ok 3/19 ... repository is empty 3/20 ... ok 3/21 ... ok 3/22 ... ok 3/23 ... ok 3/24 ... ok 3/25 ... ok 3/26 ... ok 3/27 ... ok Running /home/git/gitlab-shell/bin/check Check GitLab API access: OK Redis available via internal API: OK
Access to /home/git/.ssh/authorized_keys: OK gitlab-shell self-check successful
Checking GitLab Shell ... Finished
Checking Sidekiq ...
Running? ... yes Number of Sidekiq processes ... 1
Checking Sidekiq ... Finished
Checking Reply by email ...
IMAP server credentials are correct? ... yes Init.d configured correctly? ... yes MailRoom running? ... yes
Checking Reply by email ... Finished
Checking LDAP ...
LDAP is disabled in config/gitlab.yml
Checking LDAP ... Finished
Checking GitLab ...
Git configured correctly? ... yes Database config exists? ... yes All migrations up? ... yes Database contains orphaned GroupMembers? ... no GitLab config exists? ... yes GitLab config up to date? ... yes Log directory writable? ... yes Tmp directory writable? ... yes Uploads directory exists? ... yes Uploads directory has correct permissions? ... yes Uploads directory tmp has correct permissions? ... yes Init script exists? ... yes Init script up-to-date? ... yes Projects have namespace: ... 3/1 ... yes 3/2 ... yes 3/3 ... yes 3/4 ... yes 3/5 ... yes 3/6 ... yes 3/7 ... yes 11/8 ... yes 6/9 ... yes 3/10 ... yes 15/11 ... yes 3/12 ... yes 6/14 ... yes 3/16 ... yes 3/17 ... yes 3/18 ... yes 3/19 ... yes 3/20 ... yes 3/21 ... yes 3/22 ... yes 3/23 ... yes 3/24 ... yes 3/25 ... yes 3/26 ... yes 3/27 ... yes Redis version >= 2.8.0? ... yes Ruby version >= 2.3.5 ? ... yes (2.4.4) Git version >= 2.9.5 ? ... yes (2.19.1) Git user has default SSH configuration? ... yes Active users: ... 18
Checking GitLab ... Finished
Possible fixes
It's possible that this is related to #61441 (moved) in that the authentication logic for Google OAuth 2.0 provider should check and link the accounts for the initial login?
Sorry I didn't have a chance to dig into the ruby codebase to find the possible clue.