Personal Access Tokens

Personal Access Tokens, also known as PATs, are being used to replace the usage of passwords for authentication of third-party clients (ex: VS Code) to your resources (ex: your GitHub Repositories) in another server. It acts similarly to OAuth tokens but conceptually, in OAuth, the token is requested, received, and used solely by the third-party client (only the consent is given by the user) but in PAT, the user (resource owner) creates the token and gives the token to the third-party client. Therefore, the user is the main person in charge of managing the tokens.

In this article, my main objective is to discuss some characteristics and the usage of PAT across a few domains such as GitHub, Okta, LaunchDarkly, Microsoft Azure DevOps, and GitLab.

GitHub PAT

The user can create PATs simply by guiding through the UI in the GitHub web app. Permissions that should be granted for the token can be adjusted with the use of scopes. Therefore, the user can grant only the minimum required permissions to the client. For example, if the client should not be able to delete the repo, “delete_repo” scope must be unticked at the token creation. Therefore, the bearer of the token will not be able to delete any of your repositories.

The following steps illustrate how to generate a PAT through the GitHub web app.

1. Go to the “Settings” section. (get the menu from the profile pic icon at the top right-hand corner)

2. Select the “Developer Settings” tab in the left menu.

3. Select the “Personal Access Token” tab.

4. Click on the “Generate new token” button.

5. Type in a name (that describes the purpose of the token) inside the “Note” section and select an expiry date for the token.

6. Check the boxes with needed scopes. (leave the other scopes unchecked)

7. Click on the “Generate token” button at the bottom.

8. Copy and save the displayed token somewhere secure. (You cannot view the token again)

An expiry time (optional but highly recommended) will be associated with a PAT, and thus, after the specified expiry date, the token will be invalidated. If the user still needs the client to have access to the repos, a new PAT can be generated.

Every generated PAT will be associated with a name and can be referenced by that name. All the created tokens of the user can be viewed through the GitHub web app and at any time, the user has the authority to revoke any token, the user created. Unused tokens in one year are removed by GitHub automatically.

Okta API Tokens

These tokens are quite similar to GitHub PATs and can be created using the Okta Admin Console by guiding through the UI in the same way as described in GitHub PAT. But the main difference between GitHub PAT and Okta API Tokens is the method of permission allocation for tokens. In Okta API Tokens, the tokens will get the same privilege as the creating user and thus, the same permissions as the creating user. Therefore, if the permissions of the user get changed, the permissions of all the tokens, that the user created, will also get changed.

Expiry time for all the tokens is fixed and it is 30 days after the creation or last use. These tokens can also be revoked at any time by the user. If the user account gets deactivated, the tokens owned by that account will also be revoked.

LaunchDarkly API Access Tokens

LaunchDakrly also provides an API Access Token that is similar to the above described PAT types. These tokens can be generated by guiding through the UI in the Account Settings Page of their web app in the same way as the above described token types. In LaunchDarkly, there are two types of tokens.

1. Personal Tokens — These tokens are attached to the user account that created them. If the permissions of the user get reduced, the scope of the token will also get reduced.
2. Service Tokens — These tokens are not attached to the user account that created them and therefore, the tokens will have a fixed set of permissions.

Scopes for a token will be allocated through roles and therefore, a role that has the necessary set of scopes will be assigned to the token. The user can use Bult-in roles as well as custom roles according to their preferences.

After the creation of tokens, the user is allowed three actions on the tokens.

1. Clone — Create tokens with the same set of permissions as the selected token.
2. Edit — Change properties of a selected token.
3. Delete — Revoke the token.

A token will be only displayed once (at the creation) and later it will be referred to by its name.

Microsoft Azure DevOps PAT

These personal access tokens can be created in two ways.

1. Using the Azure DevOps home page (guiding through the UI). [similar to above token types]
2. Using the PAT Lifecycle Management API. (Prerequisite — Azure AD tenant with an active Azure subscription)

At the creation of tokens, the expiry time and the scopes are specified as needed. The user is notified by email about expiring tokens that are going to be expired in 7 days.

Users can modify the expiration dates and scopes of a token after the creation.

GitLab PAT

There are three ways to create PATs in Gitlab.

1. Using the API endpoint (GitLab API)
2. Using the web app (guiding through the UI)
3. Create the token programmatically through gitlab-rails console (directly typing a 20 characters long string)

These PATs also have the same characteristics as GitHub PATs. So, simply put, the user can create, view, and revoke tokens at any time. Permissions for a token are specified through scopes. The user is notified by email about expiring tokens that are going to be expired in 7 days and in one day.

Common Characteristics of PAT

The following points describe all the main and common attributes of PAT in different domains that were discussed above.

1. User can create, modify (edit permissions or extend expiry time) and revoke tokens inside the Web App by guiding through the UI. [ alternative — User can create a token programmatically (maybe through a console or CLI) directly typing in a string and this string will be used as the token.]
2. The token will be associated with a name.
3. Token will be displayed only once, and after that, the token is only referred to by the name. (After that it will be hashed and stored and the original token will be deleted.)
4. User can view all the previously generated tokens by their name in the Web App. (for modifications, revocations, and check unusual token generations)
5. User can specify the permissions through the following two methods (6 and 7).
6. Scopes — user can give permissions accordingly (limited access). (But max permissions that can be given to a token are all user’s permissions and none other).
7. Get the permissions as same as the creating user.
8. User can select an expiry time at the token creation and it can be extended using the console as mentioned above. (There can be an option not to enforce an expiry time, in case of a highly trusted client)
9. Also, it can be programmed to revoke the token after some specific days (like 14 days) since the last use.
10. If any tokens expire on that day, the user will be notified by email. (This can be done in several intervals like 7 days to expiry, one day to expiry and so on)
11. If a user account gets disabled or locked, all the tokens that were created by the above user account will also be disabled or locked (or maybe revoked).
12. A Special Cloning Feature can be there to generate new tokens that have permissions as same as a previously generated token. (No need to specify the permissions again)