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.
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-Tokenheader as in
curl --header "PRIVATE-TOKEN: $TOKEN".
OAuth 2.0 Bearer tokens should be passed using the
Authorizationheader and adding the authentication scheme to the token (
Bearerin our case) eg.
curl --header "Authorization: Bearer $TOKEN".
We already accept OAuth 2.0 Bearer tokens but we authenticate them using the
doorkeepergem which uses its own database table. (We use
doorkeeperto 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 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.
- Personal Access Token Documentation
- API Docs for authenticating with PAT will need to be expanded to show how to authenticate with OAuth2 headers.
- Test that we avoid collisions and do not authenticate
- Test that the new PAT works with the NPM Registry.
What does success look like, and how can we measure that?
Long-term success looks like we have unified all of our access tokens behind a single access token to rule them all.