What is the difference between OAuth2 client and provider?

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?

Hi AndreKR,

I’ll try my best to explain the two workflows.

https://gitlab.com/help/api/oauth2.md

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

https://gitlab.com/help/integration/oauth_provider.md

The second workflow is explaining the use of GitLab as an OAuth service provider for logging into other applications using GitLab CE/EE credentials.

Both documents do have similar steps but are focused on achieving different outcomes.

Let me know if you have any further questions.

Thanks,
Chris

2 Likes

The docs definitely need some update, thanks for bringing this up @AndreKR and thanks @MrChris for your answer :slight_smile:

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.

Or am I missing something?

Hi AndreKR,

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!

Chris

@MrChris Done: https://gitlab.com/gitlab-org/gitlab-ce/issues/15658

1 Like

Hi,
I am looking to use OAuth2/OpenID Connect with Gitlab as a client and have not been able to find proper documentation.

Anyway. The first link on the first post above points to a page with this heading:

GitLab as an OAuth2 provider
This document covers using the OAuth2 protocol to allow other services access Gitlab resources on user’s behalf.

Isn’t the heading supposed to be: GitLab as an OAuth2 client ?

Meanwhile, if someone here can help me with using Gitlab as an OpenID connect client (as opposed to an OpenID provider), I will really appreciate it.

No, both documents describe a workflow to use GitLab as an authentication provider.

GitLab’s OAuth2 client functionality is called “OmniAuth” and is described here: https://docs.gitlab.com/ce/integration/omniauth.html

Thanks for correcting me @AndreKR