🚀 Feature: allow client secret w/ PKCE #435

New Issue

OVERLORD · 2025-10-08T00:08:31+03:00

OVERLORD commented

2025-10-08 00:08:31 +03:00

Originally created by @cdanis on GitHub.

Feature description

Other IDPs support using client secret with PKCE as a cheap, simple, extra layer of security. It's probably trivial to add to pocket-id.

Pitch

At a high level, PKCE allows the authorization server to validate that the client application exchanging the authorization code is the same client application that requested it and that the authorization code had not been stolen and injected into a different session.
On the other hand, client authentication (e.g. a client secret) allows the authorization server to validate the client application’s identity, proving that it is allowed to swap an authorization code in the first place.
...
PKCE allows the authorization server to ask, “Is the app that is trying to swap the code for a token the same application that I sent it to? Is it as a result of the correct authorization request?”. If an attacker steals an authorization code, then this verification is vital. Client authentication alone wouldn’t help you here.
...
PKCE is now a recommendation for server-side applications in OAuth 2.1, clarified with:

Historic note: Although PKCE [RFC7636] was originally designed as a mechanism to protect native apps, this advice applies to all kinds of OAuth clients, including web applications and other confidential clients.
-- oauth v2.1 draft spec

-- The above from https://www.scottbrady.io/oauth/client-authentication-vs-pkce

Originally created by @cdanis on GitHub. ### Feature description Other IDPs support using client secret with PKCE as a cheap, simple, extra layer of security. It's probably trivial to add to pocket-id. ### Pitch > At a high level, PKCE allows the authorization server to validate that the client application exchanging the authorization code is the same client application that requested it and that the authorization code had not been stolen and injected into a different session. > On the other hand, client authentication (e.g. a client secret) allows the authorization server to validate the client application’s identity, proving that it is allowed to swap an authorization code in the first place. > ... > PKCE allows the authorization server to ask, “Is the app that is trying to swap the code for a token the same application that I sent it to? Is it as a result of the correct authorization request?”. If an attacker steals an authorization code, then this verification is vital. Client authentication alone wouldn’t help you here. > ... > PKCE is now a recommendation for server-side applications in OAuth 2.1, clarified with: >> Historic note: Although PKCE [RFC7636] was originally designed as a mechanism to protect native apps, this advice applies to all kinds of OAuth clients, including web applications and other confidential clients. > -- oauth v2.1 draft spec -- The above from https://www.scottbrady.io/oauth/client-authentication-vs-pkce

OVERLORD added the feature label 2025-10-08 00:08:31 +03:00

OVERLORD closed this issue

2025-10-08 00:08:32 +03:00

OVERLORD commented

2025-10-08 00:08:35 +03:00

@stonith404 commented on GitHub:

Added in v0.23.0.

@stonith404 commented on GitHub: Added in `v0.23.0`.

OVERLORD referenced this issue

2025-10-08 00:17:26 +03:00

[PR #457] [MERGED] feat: add ability to send login code via email #801

Sign in to join this conversation.