Closed rogerbn closed 10 months ago
PKCE is an extension of the authorization code flow (https://oauth.net/2/pkce/), so I see no reason why it would go against the stated design principle.
The OAuth 2.1 specification (https://oauth.net/2.1/) goes as far as to require PKCE for all clients using the authorization code flow.
@johngian Do you plan to review and merge pull request?
It doesn't make sense to me for this package, which is a Django package intended for the server side, to implement the PKCE flow, which is something intended for an app where a client secret doesn't make sense since it could be de-compiled/compromised. In other words, the PKCE flow only makes sense within a native iOS or Android app, or an SPA, so in some kind of Swift, Android, or client-side JavaScript package.
PKCE is now widely recommended for use in more contexts than that in more recent standards.
@maxb Do you know of a recommended use case for the PKCE flow on the server-side? It seems to me that on the server side of things, the "Authorization Code" flow, with its use of a private client secret instead of PKCE's random code verifier and code challenge, would always be preferred, but maybe I'm missing something? Perhaps server-side PKCE flow is a nice option because it doesn't depend on a static secret that could be stolen? Could you point us to where PKCE is recommended on the server side?
An RFC documenting OIDC 2.1, a rollup of the many documents that have tweaked bits of OIDC 2.0 since its creation, is currently in draft with the IETF: https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/
PKCE is now recommended for all usage of the Authorization Code flow:
7.6. Authorization Codes
To prevent injection of authorization codes into the client, using code_challenge and code_verifier is REQUIRED for clients, and authorization servers MUST enforce their use, unless both of the following criteria are met:
The client is a confidential client.
In the specific deployment and the specific request, there is reasonable assurance by the authorization server that the client implements the OpenID Connect nonce mechanism properly.
In this case, using and enforcing code_challenge and code_verifier is still RECOMMENDED.
The code_challenge or OpenID Connect nonce value MUST be transaction- specific and securely bound to the client and the user agent in which the transaction was started. If a transaction leads to an error, fresh values for code_challenge or nonce MUST be chosen.
Historic note: Although PKCE [RFC7636] (where the code_challenge and code_verifier parameters were created) 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.
(Bold emphasis my own.)
Also:
4.1.1. Authorization Request
...
Clients use a unique secret per authorization request to protect against authorization code injection and CSRF attacks.
@maxb I wasn't aware of that, thanks for sharing that link to the RFC doc and enlightening me!
@jaap3 I only just realized that your links also answered my questions and would have enlightened me as well, so apologies for overlooking those, and a belated thank you! 😄
Would love to see this feature added (I also 👍 ed it up).
I'm using latest version from main branch (commit 71e4af8).
Seems PKCE is not working in SessionRefresh
middleware because my OIDC provider (Keycloak) return invalid_request
error with description Missing parameter: code_challenge_method
.
If I put OIDC_AUTH_REQUEST_EXTRA_PARAMS = {"code_challenge_method": "S256"}
in settings, then OP return invalid_request
error with description Missing parameter: code_challenge
.
P.S. This library is awesome, thank you!
Fixed in v4.0.0
@akatsoulas is OIDC_USE_PKCE documented in the readthedocs?
@VictorioBerra the building of the docs was failing. Should be restored now
Could support for Code authorization flow with PKCE be added to mozilla-django-oidc ? or does that go against design priciple "Mainly support OIDC authorization code flow"`?