Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Code authorization flow with PKCE #397

Closed
rogerbn opened this issue Mar 3, 2021 · 13 comments
Closed

Code authorization flow with PKCE #397

rogerbn opened this issue Mar 3, 2021 · 13 comments

Comments

@rogerbn
Copy link

rogerbn commented Mar 3, 2021

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"`?

@jaap3
Copy link
Contributor

jaap3 commented Oct 18, 2021

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.

@themooer1 themooer1 mentioned this issue Dec 29, 2021
@krzysieqq
Copy link

@johngian Do you plan to review and merge pull request?

@escattone
Copy link
Contributor

escattone commented Dec 2, 2022

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.

@maxb
Copy link

maxb commented Dec 2, 2022

PKCE is now widely recommended for use in more contexts than that in more recent standards.

@escattone
Copy link
Contributor

escattone commented Dec 2, 2022

@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?

@maxb
Copy link

maxb commented Dec 4, 2022

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.

@escattone
Copy link
Contributor

@maxb I wasn't aware of that, thanks for sharing that link to the RFC doc and enlightening me!

@escattone
Copy link
Contributor

@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! 😄

@mooreds
Copy link

mooreds commented Feb 6, 2023

Would love to see this feature added (I also 👍 ed it up).

@soul-catcher
Copy link

soul-catcher commented Feb 16, 2023

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!

@akatsoulas
Copy link
Collaborator

Fixed in v4.0.0

@VictorioBerra
Copy link

@akatsoulas is OIDC_USE_PKCE documented in the readthedocs?

@akatsoulas
Copy link
Collaborator

@VictorioBerra the building of the docs was failing. Should be restored now

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants