Description
Currently, the OAuth2 authentication module in Cortex supports the standard Authorization Code flow. However, many modern Identity Providers (IdPs) now strictly require or strongly recommend using PKCE (Proof Key for Code Exchange) for enhanced security.
Without PKCE support, integrating Cortex with these modern SSO environments can be problematic or completely blocked by strict enterprise security policies.
Proposed Solution
I propose adding PKCE support to the existing OAuth2 flow in Cortex, while keeping it 100% backward compatible for existing installations.
The implementation would include:
- Adding a new configuration boolean parameter
auth.oauth2.pkce (defaulting to false) for Cortex application.conf.
- If enabled, dynamically generating a
code_verifier and its hashed code_challenge (S256).
- Appending the
code_challenge to the initial authorization URL.
- Retrieving the
code_verifier from the session and sending it in the payload during the final token exchange request.
Alternatives Considered
Leaving the implementation as-is forces administrators to lower their IdP security requirements. Forcing PKCE for everyone might break integrations with older IdPs that do not tolerate unknown parameters. Making it configurable solves both issues.
Description
Currently, the OAuth2 authentication module in Cortex supports the standard Authorization Code flow. However, many modern Identity Providers (IdPs) now strictly require or strongly recommend using PKCE (Proof Key for Code Exchange) for enhanced security.
Without PKCE support, integrating Cortex with these modern SSO environments can be problematic or completely blocked by strict enterprise security policies.
Proposed Solution
I propose adding PKCE support to the existing OAuth2 flow in Cortex, while keeping it 100% backward compatible for existing installations.
The implementation would include:
auth.oauth2.pkce(defaulting tofalse) for Cortex application.conf.code_verifierand its hashedcode_challenge(S256).code_challengeto the initial authorization URL.code_verifierfrom the session and sending it in the payload during the final token exchange request.Alternatives Considered
Leaving the implementation as-is forces administrators to lower their IdP security requirements. Forcing PKCE for everyone might break integrations with older IdPs that do not tolerate unknown parameters. Making it configurable solves both issues.