Are you planning to support recommendations given in https://tools.ietf.org/id/draft-parecki-oauth-browser-based-apps-00.html?
Auth0.js does not support Authorization Code flow or the PKCE feature. Would like to see a commitment for supporting that.
Until further, we are looking into using Appauth-js instead, and marking our SPA as Native to get the PKCE support. Is this a valid approach in your opinion?
Correction: We will not need to falsely mark the SPA as Native in order to get the PKCE codes verified by Auth0. It seems that Auth0 validates PKCE when present, regardless of application type. The documentation had me believe otherwise…
Seems also that Auth0 does not support the response_mode “fragment” for Authorization Code Grant. This makes it less suitable for implementing Auth Code Grant for a browser based application (like a SPA), where you want the “fragment” mode and not “query” mode.
Thanks for the topic and sorry for the delay in response. Here is where we currently stand:
The OAuth2 working group is working on a set of new best practices. The discussion is ongoing, and Auth0 is an active participant in it. There are still important details that need to be ironed out before the practices discussed will be fully actionable. And even when they will be finalized, the document remains a best practice - that means that it doesn’t amend anything in the standard specifications, which remain normative.
The best practices discussion is not happening as response to any new vulnerability discovery; the challenges associated to the implicit flow have been known and documented for a long time, and SDKs & associated code contain mitigations designed to manage the risk. Consequently, the sheer fact that those discussions are happening doesn’t call for immediate action in itself.
The best practices being discussed do have tangible advantages in respect to the current approach, hence in the fullness of time the industry (including Auth0) is likely to adopt them. We are actively prototyping them to ensure that we can offer support for them in our product. However in the short term nothing changes, the existing approach, SDKs and attention points remain the mainstream tools used to address the single page app scenario. As our guidance evolves, we will make sure to communicate it timely and broadly.
Hi Jeremy, thanks for responding.
I know there is really nothing new that makes the Implicit flow worse than before. Still, these discussions I feel give more weight to those (including me) who feel that the Implicit flow is not a good idea. Especially so when we are building a new application. In the words of some security experts, the Implicit flow is to be regarded as deprecated. And I agree with what the recommendations aim for.
I also appreciate that there will be some time until it consolidates into a solid (standard) approach to implement for AS/IP like Auth0.
But as we are building a new system, and the use of Authorization code flow with PKCE is not that far off, I want to recommend we take that path. At least as an intermediate solution. There might even be a way for us to move all token handling to server side, but that is farther down the road.
So now I know you will wait for the discussions and recommendations to settle.
I made a proof of concept converting the Auth0 example SPA app to Auth code/PKCE using the AppAuth.js library. The only quirk was that response mode did not support “fragment” for Auth code grant type.
In your opinion are there any strong arguments against going with this approach?
And would you please consider supporting response mode “fragment” for Auth code grant type?
BR
/Martin
I am marking this as solved with reference to this post:
The auth.js will be updated to support code grant with PKCE. Hopefully soon. 
/Martin
We’ll get community informed here once there will be any changes introduced! Thanks a lot @martin.osterberg!
This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.