1. Proposed title of this feature request

Support direct API authentication with Microsoft Entra v2.0 tokens.

2. What is the nature and description of the request?

The customer requests that Red Hat Quay be updated to act as an OIDC Resource Server capable of validating Microsoft Entra ID v2.0 Access Tokens directly against the Quay API.  Currently, when the OIDC_ISSUER is configured for Microsoft, Quay enforces strict validation logic that only accepts the legacy v1.0 issuer (sts.windows.net).

The customer requires Quay to allow the v2.0 issuer (https://login.microsoftonline.com/\{tenant_id}/v2.0) to support modern authentication flows.

Specific capabilities requested:

• v2.0 Issuer Support: Allow the config.yaml to accept login.microsoftonline.com as a valid issuer, removing the hardcoded requirement for the legacy STS endpoint.
• Direct Bearer Token Access: Allow a user (or automation tool acting as a user) to pass an Entra ID Access Token in the Authorization: Bearer header to perform API actions (e.g., creating organizations, managing permissions) without first exchanging it for a Quay token.

• On-Behalf-Of (OBO) Flow Support: The customer uses Red Hat Developer Hub (RHDH).  RHDH authenticates the user and then requests a downstream token to talk to Quay on behalf of that user.  Quay must be able to validate these OBO tokens, which may contain a custom Audience (aud) claim representing the Quay API, rather than the Client ID. (https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-on-behalf-of-flow.)

Note on existing "Keyless" features: The customer is aware of the "Robot Account Federation" (Token Exchange) feature introduced in Quay 3.13.  They have explicitly stated this request is for a different use case where they need to use the OIDC token directly against the API, rather than exchanging it for a robot credential.

3. Why does the customer need this? (List the business requirements here)

Business requirements: The customer is implementing a "Zero Trust" security architecture.  They require "Keyless" authentication for all internal APIs to eliminate the security risk of managing long-lived static secrets (such as Quay OAuth2 tokens or Robot Account passwords).

Technical requirements/blockers:

• Modern auth flows: The customer uses Red Hat Developer Hub (Backstage) and Red Hat Dev Spaces. These tools use modern OAuth flows (OBO Flow and Device Code Flow) which default to issuing Entra v2.0 tokens.

• Incompatibility: When these v2.0 tokens are sent to Quay, they are rejected with "Issuer https://login.microsoftonline.com/... not configured", blocking the integration.

• Inconsistent behavior: The customer reports that "some" API calls work while others fail.  This suggests inconsistent validation logic in the Quay API layer that needs to be standardized to support v2.0 officially.

• Legacy endpoint deprecation: The customer challenges why Red Hat recommends the legacy sts.windows.net endpoint, as Microsoft documentation treats v2.0 as the current standard for new integrations.

4. List any affected packages or components

• Quay configuration: config.yaml parsing for OIDC_ISSUER and OIDC_PROVIDERS (specifically type azure).

• Authentication backend: The current OIDC middleware that parses the JWT iss (issuer) and aud (audience) claims.

• Documentation: Updates required to remove the warning against using login.microsoftonline.com and document the v2.0 configuration.