PKCE should not be mandatory
arielsegura opened this issue · comments
Checklist
- The issue can be reproduced in the nextjs-auth0 sample app (or N/A).
- I have looked into the Readme, Examples, and FAQ and have not found a suitable solution or answer.
- I have looked into the API documentation and have not found a suitable solution or answer.
- I have searched the issues and have not found a suitable solution or answer.
- I have searched the Auth0 Community forums and have not found a suitable solution or answer.
- I agree to the terms within the Auth0 Code of Conduct.
Description
Following up on this solved issue, OAuth2 recommends, but does not enforce the usage of PKCE. At the moment, this is inferred by the usage of code as a response type.
To give an example, the Spotify authentication documentation recommends using PKCE in cases where storing the client secret is not safe, such as in mobile apps or javascript client side. However, for the case of NextJS SSR, it is possible to not expose the client secret at all. What's more, I believe the oauth token endpoint is invoked by the Auth0 tenant directly, which uses the client secret anyway. So while PKCE makes sense for the auth0-spa-js, as it fully runs on the client, for the case of NextJS, this should not be mandatory.
https://developer.spotify.com/documentation/web-api/concepts/authorization
Reproduction
- Run the example
- Inspect the /authorize endpoint that goes to the auth0 tenant, and you will notice the PKCE parameters there. Even when using SSR pages and no client code at all.
Additional context
No response
nextjs-auth0 version
3.5.0
Next.js version
13.4.9
Node.js version
v18.17.0
Thanks for reaching out. Even though you are right, with OAuth 2.1, the idea is to enforce PKCE everywhere when using the code flow, see https://oauth.net/2.1/.
Sure, we are not at OAuth 2.1 yet, but I don't see why we should move away from using PKCE in this case, as it should be an implementation detail that should not affect you. We are basically just already implementing the recommendation that is going to be enforced in a specification with OAuth 2.1.
Can you elaborate on why you can not use PKCE and why you think we should allow to use the code flow without PKCE?
Ah thanks for explaining! That makes sense.
I found this behavior while debugging another issue I'm facing. I was first confused about why the PKCE params where included if I was not opting in for that.
IMO The problem with the current implementation of PKCE is that it uses cookies under the hood, and in my context, I want to optimize for a login that doesn't rely on cookies, as my users are very likely to trigger the login in one (in-app mobile) browser, and end in another one (iOS or Android default system browser), where the cookie won't be available and auth0 simply crashes.
Allowing the code flow without PKCE won't fix my use case, but it's another reason to rely on cookies. I also wonder how this use case will be supported by OAuth 2.1.
IMO The problem with the current implementation of PKCE is that it uses cookies under the hood
As you mentioned yourself, the PKCE isn't the only reason we rely on the cookie, we also validate the nonce and max_age before finishing the transaction and exchanging the code for tokens. Well, I say "we", but that validation happens in the openid_client we use here. Because of the fact that we need such a transaction, we need to start and finish the authentication in the same browser. When implementing this yourself, I assume you can find additional ways to transfer those values.
Closing this issue, as the focus here is on the PKCE and I would recommend to get in touch with our professional services to get to a working solution, then circle back to a specific SDK that would support your use-case.
I understand the logic for closing this issue but OP has a point.
We integrated at my company last year a POC flow with the deprecated Web SDK, yet we managed to implement it with Authorization Code flow, but without PKCE.
I can contact our dedicated Auth0 service as you suggest, they are very useful, and we can certainly add the code_verifier in our new implementation.
But I feel that being unable to opt out of PKCE with the Next SDK is not cool and if I understood, PKCE flow only makes sense for Single-page apps and Native mobile apps, which Next is not as we use its API.
we can certainly add the code_verifier in our new implementation.
@Temperantia Can you elaborate what you mean with that you can add code_verifier in your new implementation?
This SDK is for auth0, which uses pkce just fine when you use this SDK. There shouldnt be anything for you to do, it shouldnt even matter for you as it's an implementation detail in our SDK, supported by auth0.
PKCE flow only makes sense for Single-page apps and Native mobile apps
As mentioned above, and in the links to the OAuth 2.1, the idea is, going forward with OAuth2.1, to use pkce everywhere where we use the code flow, including web apps (and not just SPA's or Native apps). So our SDK implements the recommendations that are to be part as a more stronger enforcement as of the next version of the OAuth specification.
We have a custom handling of the code exchange against a token on our backend service due to 3rd party additional authentication usage.
So now since a code challenge is tied initially, the tenant asks us to provide the code verifier necessarily.