Feature Overview

This feature enhances Red Hat Quay’s OAuth 2 capabilities by introducing a granular token lifecycle management system.  Currently, admins must delete an entire OAuth App to revoke a single token.

This feature allows admins to issue multiple tokens per App with a user-friendly interface for managing OAuth API tokens, giving administrators visibility into their token inventory and the ability to manage tokens without direct database access.

This is Phase 2 of the OAuth token lifecycle improvements, building on the API foundation from Phase 1 to deliver a complete UI-based token management experience.

Goals

• Granular revocation: Enable immediate revocation of a single compromised token without deleting the parent Application or affecting other active tokens.

• Enhanced visibility: Provide a centralized inventory of all tokens, including "Created By," "Last Used," and "Expiration" metadata.

• Security & Rotation: Enforce expiration policies (e.g., 30-day tokens) to support credential rotation and reduce the attack surface of long-lived credentials.

• Automation: Expose full lifecycle controls (Create, List, Revoke) via API to support CI/CD integration. (Done in Phase 1)
  
  * Enable zero-touch deployment (optional): For organizations requiring fully automated Quay deployments, provide an optional mechanism to create initial tokens without UI interaction, while maintaining security through feature flags and rate limiting. (Done in Phase 1)

Background

Currently, Red Hat Quay’s OAuth 2 Application tokens are designed to be long-lasting to support automation.  Once generated, the token secret is shown only once, and the token is valid for its full lifespan. 

This design presents two main challenges for organizations managing security at scale:

• “All or nothing” revocation: When a single token is compromised, the current method to invalidate that particular token is to delete the entire OAuth Application that issued it.  While this is an effective revocation method, it has an “an-or-nothing” effect that immediately invalidates all other tokens from that same application.  This can lead to service disruptions for other non-compromised integrations.

• Management and visibility: Visibility to active tokens often relies on reviewing audit logs, which is a reactive approach.  A common practice is to create a separate OAuth Application for every single token to enable individual naming and revocation.  While this is a valid workaround, it can create scalability challenges as the number of tokens grows.

 
Phase 1 (PROJQUAY-10436) delivered the API infrastructure for token lifecycle management.  Phase 2 now delivers the UI that makes this functionality accessible to all users.

Requirements (aka. acceptance criteria):

• Epic 1: PROJQUAY-9857 [UI] "API Access Tokens" Management Tab
  • New tab replaces legacy "Generate Token" in OAuth Application modal
  • Token list displaying: Name, Created By, Scopes, Expires, Last Used
  • "Generate New Token" wizard with name, expiration, and scope selection
  • "Revoke" action with confirmation modal
  • Legacy token handling (display as "Legacy Token")

• Epic 2: PROJQUAY-9858 [Docs] Update API & User Documentation for granular OAuth token
  • UI walkthrough with screenshots
  • Migration guide (legacy to modern tokens)
  • Security best practices

Dependencies

• Requires: Phase 1 (PROJQUAY-10436) - Programmatic OAuth Token Provisioning (backend API must be available)

Reference 

For the full collaborative design spec, background history, and detailed edge cases, please see:

• original shared document: PROJQUAY-9755: Granular lifecycle management for OAuth 2 application tokens

• This feature addresses the following RFE requirements:

  RFE	Requirement	Feature
  RFE-4324	List all tokens and permissions	Token list in UI
  RFE-4324	Manage via UI	"API Access Tokens" tab
  RFE-4324	Manage via API	Phase 1 API endpoints