Can anyone shed some light on what is the difference between the workflow described on
and the one described on
In the first link I’m assuming the thing running on localhost:3000 is supposed to be GitLab.
The two pages seem to describe different parts of the exact same thing:
The user (or an admin) creates an Application in GitLab
Ther user wants to grant some other application access to his GitLab account
The other application requests an authorization code from GitLab by sending the user to the oauth/authorize endpoint in GitLab and exchanges the code for an access token
The other application issues API requests on behalf of the user
The pages link to each other, giving the impression that they describe opposite things, but do they really do that?
The first OAuth workflow is explaining how to utilise OAuth in GitLab CE/EE to allow login from other OAuth service providers such as Facebook & Twitter. It’s also more explaining the workflow from an API standpoint.
In the first link I’m assuming the thing running on localhost:3000 is supposed to be GitLab.
Yes, the “localhost:3000” is representing a GitLab instance and is standard for the GitLab Development Kit
Thanks for your answer. If you could clarify two more things for me:
I think this is the point that confused me. If the described workflow is supposed to explain how users can use an identity provider to log in into GitLab, the shown URLs should not be localhost GitLab URLs, but instead from e.g. Facebook (/dialog/oauth + /v2.3/oauth/access_token + /me) or Google (/o/oauth2/auth + /o/oauth2/token). Correct?
I tried doing exactly this with GitLab CE 8.7.0, and it seems it is impossible with GitLab at this point.
In general, logging in into another application using a user account from a different application is basically a regular OAuth2 flow, but the only resource that is granted is the identity. This is controlled by the requested scope, which is something openid profile (Login with Google) or empty string (Login with GitHub). This scope then grants read access to identity information (usually email address or user ID/sub claim).
Now in GitLab, the only available scope seems to be api. However, this seems to grant full access to do any API request on behalf of my GitLab account.
Therefore I cannot use GitLab to log in into another application without also granting them full access to my GitLab account.
I’m happy to help. I’ve investigated this a little further and you’re correct the default OAuth scope when using GitLab as an OAuth service provider is very broad (full api access), it’s possible that the scope should be limited to read-only access.
Are you able to lodge an issue on the GitLab Community Edition repository - Please ping me (@MrChrisW) once created and we’ll get it looked into by a developer.
Thanks again for taking the time to help improve GitLab!
