Pass gl_auth_type as part of devise OmniAuth flow

What does this MR do and why?

This addresses https://gitlab.com/gitlab-org/gitlab/-/issues/337663 by reducing the API scope to read_user if we detect that the authorization flow was initiated as part of a login.

Screenshots or screen recordings

oauth

How to set up and validate locally

To validate this change, you need two running GitLab instances, both on this branch.

One (a) must be accessible to the other (if not necessarily publically acessible). The other (b) may be entirely behind a firewall. We shall call these two instances:

a. The public authenticator

b. The private delegator

We recommend running the public authenticator using GitPod, which makes setting up a publically available instance easy. Simply click on Open in GitPod in the MR information box.

The other instance can be anywhere else - a local GDK/GCK instance is fine, but you could equally have another GitPod instance if you want.

Both instances must be on this branch.

On the public authenticator:

1. As any user, log in
2. Click on AVATAR -> edit profile
3. In the LHS menu, click applications
4. Add a new application, with the following settings below, and click save
5. Copy the app_id and app_secret for this newly created application for use in setting up the private delegator.
6. Prepare a user to log-in as using OmniAuth. this does not need to be the same as the user that created the application It helps if this user has a unique username and email address, so that we can be sure when we do log in that the information came from this server. You can create this user in the admin panel.
7. Enable the feature-flag in the Rails console: Feature.enable(:omniauth_login_minimal_scopes)

Application settings:

Name: ANY_NAME
Redirect URI: http://${private-delegator-IP}:${private-delegator-PORT}/users/auth/gitlab/callback
Confidential: NO
Scopes: api (see below)

For scopes, you can leave these boxes unticked, or you can select any combination of:

• api
• read_api
• read_user

NB: it is very important that you enter the resolved IP address here (not localhost!). Use ifconfig or similar to determine the real local IP address of your private delegator instance. Although if you use a custom hostname in your gdk.yml you need to use that instead.

See https://docs.gitlab.com/ee/integration/gitlab.html for details

On the private delegator:

1. Configure the OmniAuth provider list. See your distribution for how to do this.

In the GCK, you can add a section like the following to your gck.yml file:

gitlab.yml: # merge with `gitlab-rails/config/gitlab.yml`
  development:
    omniauth:
      allow_single_sign_on:
        - gitlab
      block_auto_created_users: false
      providers:
        - name: gitlab
          app_id: '${app_id from application on public authenticator}'
          app_secret: '${app_secret from application on public authenticator}'
          args:
            scope: 'api'
            client_options: { site: "https://${host-address-of-public-authenticator}/api/v4" }

In GDK, you can add the same in $GDK/gitlab/config/gitlab.yml under the development.omniauth key.

Verification steps:

1. Sign out of both instances
2. Restart/rebuild the private delegator as needed to ensure the configuration is correctly picked up (this can be confirmed in the rails console, by reading the values of Gitlab.config.omniauth.
3. Visit the private delegator. You should see a login page with a Sign in with [GitLab.com] button.
4. Click the [GitLab.com] button
5. See that you need to login on the public authenticator.
6. Once logged in, you should see a form asking you to approve of the authorization. The abilities should be listed as Read personal information
7. Accept the authorization
8. See that you are redirected back to the private delegator, and that a new account has been created for this user.
9. In the public authenticator instance, inspect the database to see the created token. You can can run the query: select * from oauth_access_tokens. The new token should have the read_user scope.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.