Skip to content

Feat: Add PKCE (Proof Key for Code Exchange) Support for OIDC Authentication #5216

@Novapixel1010

Description

@Novapixel1010

Describe the solution you'd like

I recently tried to setup kanidm and had to disable PKCE via kanidm system oauth2 warning-insecure-client-disable-pkce so it would be nice, Implement PKCE (Proof Key for Code Exchange) RFC 7636 in Memos OpenID Connect (OIDC) flow to improve security and interoperability with modern identity providers such as Kanidm, Auth0 and Keycloak. kanidm explains why this is insecure here

Type of feature

Other

Additional context

Background

Currently, when Memos acts as an OIDC client, it performs the standard authorization code flow.
However, several identity providers including Kanidm now enforce PKCE by default for all clients even those with client secrets. Without PKCE support, Memos cannot complete login flows with these providers unless administrators explicitly disable PKCE enforcement, which weakens security.

Observed behavior

This was in the kanidm log.

🚨 [error]: No PKCE code challenge was provided with client in enforced PKCE mode.

Proposed Implementation

Add an optional PKCE toggle (enabled by default) in Memos’s OIDC configuration

everything below here was provide by Chatgpt.

So let me know if its right because I am curious it is.

Client-side flow

On each OIDC login attempt:

  • Generate a code_verifier (random 43-128 char string per RFC 7636).
  • Compute its code_challenge using SHA-256.
  • Store the code_verifier in session/local storage for the duration of the flow.

Append:

code_challenge=<base64url(sha256(verifier))>
code_challenge_method=S256

to the authorization request.

  • During the token exchange, include the original code_verifier in the POST body.

Configuration

OIDC_USE_PKCE: true # default true
or via UI checkbox “Use PKCE (S256)”.

Dependencies

No new dependencies; PKCE can be implemented with standard crypto primitives (crypto.subtle in browser, crypto/sha256 in Go backend if needed).

Backward Compatibility

  • For existing deployments where the IdP does not require PKCE, the flow continues to work.
  • For stricter IdPs (e.g., Kanidm, Auth0, Okta), enabling PKCE resolves the current authentication failures.
  • Optionally allow disabling PKCE for testing or legacy providers.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions