We’re integrating the GitLab service on our platform so that our users can sign in to their GitLab account through the OAuth 2.0 flow.
But things get complicated in the following case:
Step 1: Redirected to the GitLab page to allow access from our service.
Step 2: The user selects “sign in with Google”
Step 3: The user chooses a Google account that has not been signed up for GitLab.
-> If the user’s starting point were from the GitLab site, they would be prompted to allow access to their Google account.
However, in the case the user starts sign-in from our service, they’re redirected to our service without going through the consent page. Although an access token is successfully issued, a subsequent API request for getting user information from the GitLab account fails with a 403 error because the user has never approved access to the selected Google account.
Is there any solution to cope with this?
@Tristan I’m sorry for calling you.
May I ask you to take a look at this?
I found you, as a GitLab staff, have left helpful comments on many other API-related posts.
I desperately need your help!
Hey @dddswit, welcome to the GitLab Community Forum, and thanks for the ping! 
Unfortunately, while I’m very familiar with the GitLab API, I’m not as up to date on OAuth as it pertains to self-managed instances of GitLab. So, if you’re not an existing customer this might best be handled by someone else.
From what I know though, once Google OAuth2 OmniAuth is enabled the ideal user flow for new signups that want to use it would be to start from GitLab so that Google authorization is asked for.
Can you clarify what you mean by when they “start sign-in from our service”?
2 Likes
If I’m incorrect, maybe @gitlab-greg knows?
Thanks for the ping, @Tristan! I believe you’re correct here.
@dddswit, I’m not quite sure what the problem is, but maybe with some additional details we can get to the bottom of this.
Can you clarify what you mean by “our service”?
in the case the user starts sign-in from our service, they’re redirected to our service without going through the consent page.
By “consent page”, do you mean the Google OAuth2 login and authentication steps?
Is this problem happening on GitLab.com or a self-hosted GitLab installation?
2 Likes
Our service is Swit (https://swit.io) and supports fetching data from GitLab repositories.
This can be started with connection to the user’s GitLab account as shown below.
Clicking Connect prompts the user to sign in to their GitLab account.
Suppose that they selects Sign in with Google and enter their Google account and password, but the Google account has never been registered for GitLab authentication.
The user still will see the following Authorize page:
I think it does not make sense because the user has no GitLab account yet. Clicking Authorize redirects the user back to our service with an access token but any subsequent API request returns 403 error (because there is no GitLab account to access). This experience is really confusing to users.
I think if users attempt at signing in with an unregistered Google account or any other third-party account, they should first be prompted to complete signing up by being guided to the following page:
(This page shows up only when the user starts signing up on the GitLab site itself.)
It there any way to relieve this confusion?
- The most ideal way is to enable the OAuth 2.0 flow to help users complete signing up if they choose an unregistered third-party account.
- Another reasonable approach might be to prevent the Authorize prompt from showing up to users who are signed in with an unregistered third-party account.
Can I implement either of the above?
@gitlab-greg
@Tristan
Please take a look above.
