Skip to content

OAuth2 support with GitLab personal access token

Problem to solve

GitLab personal access tokens are the preferred way for third party applications and scripts to authenticate with the GitLab API. A user can also use personal access tokens to authenticate against Git over HTTP or SSH. They must be used when Two-Factor Authentication (2FA) is enabled or authenticating with a token in place of password.

However, the current implementation does not support OAuth2. This prevents Javascript developers from authenticating and using GitLab's NPM Registry, which requires users to authenticate using OAuth.

Intended users

Further details

The below is from: https://gitlab.com/gitlab-org/gitlab-ce/issues/62295#note_181974192 in which @ifarkas details the results of the investigation into adding Oauth2 Support to the GitLab Personal Access Token.

Our PATs are fully compliant with the OAuth2 spec, we just don't support OAuth2 style authentication with them. We currently require them to be passed in with the Private-Token header as in curl --header "PRIVATE-TOKEN: $TOKEN".

OAuth 2.0 Bearer tokens should be passed using the Authorization header and adding the authentication scheme to the token (Bearer in our case) eg. curl --header "Authorization: Bearer $TOKEN".

We already accept OAuth 2.0 Bearer tokens but we authenticate them using the doorkeeper gem which uses its own database table. (We use doorkeeper to provide OAuth2 provider functionality.)

The simplest first step here probably is to accept PATs with the same header. This can be done by modifying Gitlab::Auth::UserAuthFinders.find_user_from_access_token.

As @dzaporozhets pointed out, we should avoid collisions and not authenticate doorkeeper tokens as PATs and vice-versa.

Proposal

Modify Gitlab::Auth::UserAuthFinders.find_user_from_access_token to accept personal access tokens with the Authorization header and add the authentication scheme Bearer to the token to enable OAuth2 support.

This will allow users to use their OAuth2 enabled PAT to authenticate with the GitLab NPM Registry.

Permissions and Security

The permissions model does not need to change. We will still allow any user to create a personal access token, set an expiration date and choose the desired scope.

Documentation

Testing

  • Test that we avoid collisions and do not authenticate doorkeeper tokens as PATs and vice-versa.
  • Test that the new PAT works with the NPM Registry.

What does success look like, and how can we measure that?

Short-term success looks like we have enabled the personal access token to work with OAuth2 headers and Javascript developers can authenticate with the NPM Registry using their PAT. We can measure short-term success by working with the customers who have specifically requested this feature and validating that the update meets their needs.

Long-term success looks like we have unified all of our access tokens behind a single access token to rule them all.

Links / references

Edited by Tim Rizzi