Goal: Increase security and flexibility when automating Quay via its REST API by empowering users to create API tokens self-sufficiently.

Why is this important?

In the current implementation, getting the API tokens required to start scripting against the Quay API is only possible in the context of an organization. Specifically, only users with the administrator role can produce API tokens (as part of creating Oauth2 Applications). This limits the ability of less privileged users to use Quay, effectively restricting them to the UI. Consequently, giving users API access to Quay requires elevating their permissions, which is against the least privilege principle. Alternatively, organization administrators could hand out API tokens, which complicates auditing for Quay in regulated environments because there is no owner information on the API token. The owner is currently the organization entity itself, which prevents tying API tokens to individuals responsible for them, which contradicts contemporary compliance rules (e.g., SoX).

Scenarios:

1. A user in Quay.io who is not a member of any organization wants to leverage Quay's REST API to integrate with their own automation. They can do that by creating an API token in their user account.
2. A user in Quay.io who is a member of an organization but does not have the administrator role wants to leverage Quay's REST API to integrate content/entities in the organization with their own automation. They can do that by creating an API in the context of an organization whose scope is limited to that of the organization.
3. A user in Quay.io who is a member of multiple organizations but does not have the administrator role wants to leverage Quay's REST API to integrate content/entities in these organizations with their own automation. They can do that by creating an API token in the context of their user account whose scope is limited to a subset of the organizations they have access to or without any limit.
4. The existing permission aspects of API tokens are unchanged:
   • an API token acts on the behalf of the specific user that created it
   • an API token can be scoped to to a subset of permissions
   • the permissions of an API token can never exceed the permissions / role of the user that created it

Acceptance criteria:

• Users can manage API tokens in their user account
  • they can create them in the context of an Oauth application following the existing "Application" concept from organizations (including application name, callback URL etc)
  • they can create them alternatively using a simpler flow that only captures mandatory information: human readable token name and optionally an expiry date
  • they can see a list of all tokens, both active and expired) as opposed to just a list of applications
• User can optionally limit API tokens to a set of organizations or a single organization
• Users can optionally scope API tokens to a subset of permissions
  • Organization management (CRUD access to robots, teams, membership and all org-level properties including org lifecycle) on existing orgs
  • Repository management (CRUD access to robots, teams and user and all repo-level properties including repo lifecycle) on existing repos
  • Organization creation
  • Repository creation
  • Repository read-access (view and pull)
  • Repository write-access (read/write to any accessible repositories)
  • User account administration
  • User account read-access
• Users-managed API tokens are always naturally limited by the permissions of the users owning the token
  • the UI will not allow to select more permissions than the user currently has
  • when user permissions are reduced over time, this is affecting the permission scope of the tokens owned by this user as well
• Users will get a section in the UI to manage their API tokens, including:
  • getting a list of existing tokens, with their name, scope and expiry date and when it was last used
  • the ability to view the details of a particular (and its Oauth application data if present)
  • the ability to refresh tokens in-place which is a shorthand for invalidating an existing token and recreate it with the same scope, name, settings etc
  • the ability to delete tokens
  • the ability to change the expiry date of tokens (including expiring it right away)
• this user UI is supplemented by a new API
• In a new organization UI screen that is separate from the existing organization application screens, organization owners can leverage the same flow as users to create API tokens limited to their organizations, they can do that directly from the organization UI
• Existing organization tokens remain available but are referred to as "Legacy Application Tokens" in the UI and that entire concept can be disabled with config tunable, resulting in:
  • removal of the UI screens
  • disabling the respective API endpoints
  • immediate expiry of any existing organization tokens

Open Questions: 

• should we fold in organization application UI screens into the new user-based token management inside the organization UI?