Chapter 2. OAuth 2 access tokens
OAuth 2 access tokens authenticate users to the Red Hat Quay API for applications that require user identity verification. You create a token for an organization OAuth application and select scopes that authorize API actions.
Although OAuth 2 tokens authorize actions on API endpoints based on the scopes that you define for the token, Red Hat Quay role-based access control (RBAC) still governs access to the resources. You can create actions on a resource, for example a repository, when you have the proper role (Admin or Creator) for that namespace. This is true even if the API token was granted the repo:admin scope.
You can create OAuth 2 access tokens by using the Red Hat Quay UI or by using the organization application token API.
When you create an OAuth 2 token, you can select the following options:
- Name. A user-defined identifier for the token.
- Expiration. A lifetime for the token. Use short expirations for scripts and CI systems when practical. Use no expiration only for controlled bootstrap cases.
Scopes, which can include the following permissions:
- Administer Organization. Administration of organizations, including creating robots, creating teams, adjusting team membership, and changing billing settings.
- Administer Repositories. Administrator access to all repositories to which the granting user has access.
- Create Repositories. Creation of repositories in namespaces where the granting user can create repositories.
- View all visible repositories. Viewing and pulling all repositories visible to the granting user.
- Read/Write to any accessible repositories. Viewing, pushing, and pulling to repositories where the granting user has write access.
- Super User Access. Administration of the installation, including managing users and organizations from the superuser panel.
- Administer User. Administration of your account, including creating robots and granting them repository permissions.
- Read User Information. Reading user information such as username and email address.
The API Access Tokens page can show additional columns such as Created By, Expires, and Last Used so that you can audit tokens without deleting the parent application.
The token secret is shown only when the token is created. Store it securely. Do not share token secrets through insecure channels.
OAuth 2 access tokens are passed as a Bearer token in the Authorization header of an API call. The API is available from the /api/v1 endpoint of your Red Hat Quay host. For example, https://<quay-server.example.com>/api/v1. You can connect to endpoints through your browser to GET, POST, DELETE, and PUT Red Hat Quay settings by enabling the Swagger UI. Applications that make API calls and use OAuth tokens can access the API, which sends and receives data as JSON.
Organization application OAuth API tokens created through the UI support various expiration values, from 7 days to 10 years. Tokens created by using the organization application token API support custom expiration values in seconds. You can revoke tokens individually by using the API or by deleting the application in which they were created. Deleting an application revokes all tokens created within that application.
Token distributors should be mindful of the permissions that they grant when generating a token on behalf of a user, and should have absolute trust in a user before granting such permissions as Administer organization, Super User Access, and Administer User. Additionally, the access token is only revealed at the time of creation; they cannot be listed from the CLI, nor can they be found on the Red Hat Quay UI. If an access token is lost or forgotten, a new token must be created; a token cannot be recovered.
In practice, Red Hat Quay administrators can create a new OAuth application on the OAuth Applications page of their organization each time they want to create a new OAuth token for a user. This ensures that a single application is not responsible for all OAuth tokens. As a result, if a user’s token is compromised, the administrator can delete the application of the compromised token without disrupting other users whose tokens might be part of the same application.
Older tokens that you created with the previous Generate Token workflow continue to work. In the API Access Tokens list, legacy tokens might appear with a name such as Legacy Token. You can leave them in place, or replace them with named tokens that have explicit expiration policies and then revoke the legacy token.
Deleting an OAuth application still deletes all tokens that belong to that application. Prefer revoking an individual token from the API Access Tokens page when you only need to invalidate one credential.
2.1. Creating an OAuth 2 access token Copy linkLink copied to clipboard!
To create an OAuth 2 access token for Red Hat Quay API calls, you can generate a named token from an organization OAuth application in the UI.
Prerequisites
- You have logged in to Red Hat Quay as an administrator.
- You have created an organization.
Procedure
- On the Red Hat Quay UI, select your organization.
- In the navigation pane, click OAuth Applications.
Create an application if you do not already have one:
- Click Create OAuth Application.
- Enter an application name and any required application details, such as homepage URL, description, avatar e-mail, and redirect/callback URL.
- Click Create application.
- Click the name of your OAuth application.
- Click API Access Tokens.
- Click Generate New Token.
Configure the token:
- Enter a Token name.
- Set an expiration period, such as 10 years.
- Optional: Click Assign another user to assign this OAuth token to another user. When prompted, select the desired user.
Select the permissions, or scopes, for the token. For example:
- Administer Organization. This application can administer your organizations, including creating robots, creating teams, adjusting team membership, and changing billing settings. Grant this permission only when you have absolute trust in the requesting application.
- Administer Repositories. This application has administrator access to all repositories to which the granting user has access.
- Create Repositories. This application can create repositories in all namespaces where the granting user can create repositories.
- View all visible repositories. This application can view and pull all repositories visible to the granting user.
- Read/Write to any accessible repositories. This application can view, push, and pull to all repositories to which the granting user has write access.
- Super User Access. This application can administer your installation, including managing users, managing organizations, and other features found in the superuser panel. Grant this permission only when you have absolute trust in the requesting application.
- Administer User. This application can administer your account, including creating robots and granting them permissions to your repositories. Grant this permission only when you have absolute trust in the requesting application.
- Read User Information. This application can read user information such as username and email address.
- Click Generate token.
Review the requested permissions, then click Authorize Application. Confirm the authorization when prompted.
ImportantAssign only the scopes that the token holder needs. Treat Administer Organization, Super User Access, and Administer User as high-trust permissions.
Copy and store the access token secret.
ImportantThis is the only opportunity to copy the token secret. Red Hat Quay does not show the full secret again after you leave the page.
Verification
- Confirm that the new token appears on the API Access Tokens page for the application. The list can include the token name, creator, scopes, expiration, and last-used information when those columns are available.
Optional. Call an API endpoint with the token to confirm that it works. For example:
$ curl -X GET "https://<quay-server.example.com>/api/v1/user/" \ -H "Authorization: Bearer <access_token>"
2.2. Reassigning an OAuth access token Copy linkLink copied to clipboard!
To keep audit logs accurate when another user needs an OAuth API token, you can reassign token creation to that user from an organization OAuth application.
Organization administrators can assign OAuth API tokens to be created by other users with specific permissions. Audit logs then reflect the user who uses the token, even when that user does not have organization administrative permissions to create an OAuth API token.
This procedure works only on the current Red Hat Quay UI. The Red Hat Quay v2 UI does not currently support this procedure.
Prerequisites
You are logged in as a user with organization administrative privileges, which allows you to assign an OAuth API token.
NoteOAuth API tokens are used for authentication and not authorization. For example, the user that you are assigning the OAuth token to must have the
Adminteam role to use administrative API endpoints.
Procedure
Optional. If not already, update your Red Hat Quay
config.yamlfile to include theFEATURE_ASSIGN_OAUTH_TOKEN: truefield:# ... FEATURE_ASSIGN_OAUTH_TOKEN: true # ...- Optional. Restart your Red Hat Quay registry.
- Log in to your Red Hat Quay registry as an organization administrator.
- Click the name of the organization in which you created the OAuth token.
- In the navigation pane, click OAuth Applications.
- Click the proper application name.
- In the navigation pane, click API Access Tokens.
- Click Generate New Token.
- Click Assign another user and enter the name of the user who takes over the OAuth token.
Check the boxes for the desired permissions that you want the new user to have. For example, if you only want the new user to be able to create repositories, click Create Repositories.
ImportantThe team role within an organization defines permission control and must be configured regardless of the options selected here. For example, the user that you are assigning the OAuth token to must have the
Adminteam role to use administrative API endpoints.Solely checking the Super User Access box does not actually grant the user this permission. Superusers must be configured by using the
config.yamlfile and the box must be checked here.Click Assign token. A popup box appears that confirms authorization with the following message and shows you the approved permissions:
This will prompt user <username> to generate a token with the following permissions: repo:createClick Assign token in the popup box. You are redirected to a new page that displays the following message:
Token assigned successfully
Verification
- After reassigning an OAuth token, the assigned user must accept the token to receive the bearer token, which is required to use API endpoints. Ask the assigned user to log in to the Red Hat Quay registry.
- After the assigned user has logged in, ask them to click their username under Users and Organizations.
- In the navigation pane, ask them to click External Logins And Applications.
- Under Authorized Applications, ask them to confirm the application by clicking Authorize Application. They are directed to a new page where they must reconfirm by clicking Authorize Application.
- They are redirected to a new page that reveals their bearer token. Ask them to save this bearer token, because it cannot be viewed again.
2.3. Revoking an OAuth 2 access token Copy linkLink copied to clipboard!
To invalidate a compromised or unused OAuth 2 access token, you can revoke the token from the organization OAuth application in the Red Hat Quay UI.
Because OAuth 2 access tokens are created through the OAuth application, they cannot be rotated or renewed. If a token is compromised, revoke it through the Red Hat Quay UI.
Prerequisites
- You have created an OAuth 2 access token.
- You have permission to manage the OAuth application that owns the token.
Procedure
- On the Red Hat Quay UI, click the name of the organization that hosts the application.
- In the navigation pane, click OAuth Applications.
- Click the application name that holds the OAuth 2 token that you want to revoke.
- Click API Access Tokens.
- Click the menu kebab of the appropriate token and then click Revoke. Confirm that you want to revoke the token by clicking Revoke token.
Verification
- Confirm that the token no longer appears as an active token on the API Access Tokens page.
2.4. Rotating a legacy OAuth 2 access token Copy linkLink copied to clipboard!
To replace a legacy long-lived OAuth 2 access token, you can create a named token with an explicit expiration policy and then revoke the legacy token.
Existing legacy tokens continue to work for at least 10 years until you revoke them.
Prerequisites
- You have an organization OAuth application that already has a legacy token.
- You can update any CI system, script, or client that currently uses the legacy token.
Procedure
-
On the Red Hat Quay UI, click Organization
OAuth Applications. - Click the application name.
- Click API Access Tokens.
- Identify the legacy token to replace. Legacy tokens do not have a user-defined name, do not show a creation date, and have an expiration date of 10 years from the date of creation.
- Click Generate New Token.
Configure a replacement token:
- Enter a Token name.
- Set an expiration appropriate for the workload, for example 7 days or 10 years.
- Select the scopes required by the client.
- Click Generate Token, then click Authorize Application and confirm the authorization.
- Copy the new token secret and store it securely.
- Update the CI system, script, or client configuration to use the new token.
- Verify that the client works with the new token.
Return to the OAuth Applications page and revoke the legacy token:
- Click the application name that owns the legacy token.
- Click the menu kebab icon for the legacy token.
- Click Revoke. Confirm that you want to revoke the token by clicking Revoke token.