Repository navigation
Private vs Public clients in the Authorization / OAuth 2.1 spec #276
Description
Not sure if this is the best place for this but wanted to share my understanding of the auth spec and offer ways we could help other developers understand what's actually required in the server implementations.
Because we're requiring the PKCE code exchange flow for obtaining an access token there is no purpose / value in having a CLIENT_SECRET. The CLIENT_SECRET is intended to prove the client initiating the token exchange is the one that's receiving the token. PKCE solves this problem and the CLIENT_SECRET becomes redundant.
Furthermore developers often misunderstand what constitutes a private client. Mobile or Desktop apps are not private clients. CLI application or libraries are not private clients. The only private clients out there are web servers that store their CLIENT_SECRET in an internal secret store.
I suppose this is more of a rant against the spec that is OAuth. I understand why we would want to support CLIENT_SECRET in the spec but I imagine most developers / end users don't understand OAuth and it just bugs me ;). Feel free to close this. /end rant
Activity
CallanHP commentedon Apr 22, 2025
You will need to take this one up with the OAuth working group - this is hardly an MCP issue.
There are more flows than just Authorization Code in OAuth, and Client authentication is really important for most of those. In addition, there is very little harm in enforcing client authentication for confidential clients in a 3-legged flow, as it mitigates stealing tokens for a confidential client by an attacker who could intercept an Authz code if they were somehow able to trigger an arbitrary redirect as an additional precondition (since a PKCE challenge/verifier pair can be calculated locally with no prior information required and included in an /authorize request with the known client_id).
aaronpk commentedon May 30, 2025
Client authentication and PKCE have nothing to do with each other.
Confidential clients (there is no term "private clients" despite it sounding like the opposite of "public clients") still need to use PKCE to protect against authorization code injection attacks.
Client credentials are useful to prove the identity of the client to the AS if it is possible for the client to be provisioned with credentials.
Client credentials obtained through Dynamic Client Registration don't prove the identity of the client, but are still useful to prove that subsequent requests to the AS are made by the same instance of the client that was previously used.