Epic Goal

• Enable Quay to integrate with OIDC providers that require PKCE (Proof Key for Code Exchange) to ensure continued, secure authentication and prevent service disruption for customers.

Why is this important?

• Customers are increasingly using OIDC providers that enforce PKCE for enhanced security in the OAuth 2.0 authorization code flow. Without PKCE support, Quay cannot authenticate against these providers. This leads to a complete loss of service for customers whose identity providers mandate PKCE, making Quay non-functional and unusable in their environments. This feature is critical for security compliance and maintaining interoperability with modern identity providers.

Scenarios

1. A Quay administrator configures an OIDC provider that requires PKCE. The configuration in Quay includes an option to enable PKCE for that provider.
2. A user attempts to log in to Quay via the configured OIDC provider. The authentication flow completes successfully without any PKCE-related errors, and the user is granted access.
3. (Current state) When a user attempts to log in to Quay with an OIDC provider requiring PKCE, the authentication fails with an `invalid_request` error, stating that a `PKCE code challenge is required`.

Acceptance Criteria

• Quay can be configured to use PKCE for OIDC authentication on a per-provider basis.
• When PKCE is enabled, Quay successfully generates a `code_verifier`, creates a `code_challenge`, and includes it in the authentication request to the OIDC provider.
• Quay successfully sends the `code_verifier` in the token exchange request to complete the authentication flow.
• Users can successfully log in to Quay via an OIDC provider that requires PKCE.
• Quay documentation is updated to explain how to configure OIDC with PKCE support.
• CI - MUST be running successfully with tests automated for the PKCE flow.
• Release Technical Enablement - Provide necessary release enablement details and documents.

Dependencies (internal and external)

1. *Internal:* Investigation of the current OIDC library used by Quay to confirm its capabilities and limitations regarding PKCE. The library may need to be updated or replaced.
2. *External:* Access to a test OIDC provider environment (e.g., Keycloak, Okta) where PKCE can be strictly enforced for development and testing.

Previous Work (Optional):

1. None

Open questions::

1. Should PKCE be an explicit configuration flag, or can it be auto-detected based on the OIDC provider's discovery endpoint (`/.well-known/openid-configuration`)?
2. Does Quay need to support both `S256` and `plain` code challenge methods, or is supporting the more secure `S256` sufficient?
3. What is the estimated engineering effort and what are the potential risks or complexities in the existing authentication module?

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>