Auth0.js: PKCE Support for Javascript Client Library

[dmarjoram]

Description

No PKCE flow in the Auth0 JavaScript libraries.

Many of our teams and partners are developing SPA applications and using the Auth0 client libraries for this purpose. Many of the integration scenarios require Authorization Code Grant with PKCE to mitigate against misuse of the authorization code.

With current OAuth draft recommendations being to use PKCE over Implicit for SPA applications, can we see support in Auth0.js anytime soon.

More information here:
https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-00#section-9.8.6

Prerequisites

[X] I have checked the documentation for this library.

[X] I have checked the Auth0 Community for related posts.

[X] I have checked for related or duplicate Issues and PRs.

[ X] I have read the Auth0 general contribution guidelines.

[X ] I have read the Auth0 Code of Conduct.

Environment

Please provide the following:

• Version of Auth0.js used: 9.x
• Browser and OS version(s) affected: All
• Additional libraries or browser extensions being used that might affect behavior: None

[lbalmaceda]

There's an open beta for an SDK that specifically supports this flow for SPAs. Take a look here for more info https://github.com/auth0/auth0-spa-js/

[luisrudge]

You can read and ask questions about the open beta here: https://community.auth0.com/t/new-javascript-sdk-for-single-page-applications-in-beta/25087 - We hope you'll love it 🎉

As for PKCE support in Auth0.js, we're still having internal discussions about this and we'll have more information in the near future.

[charsleysa]

@luisrudge has there been any progress on the discussions to support PKCE in Auth0.js?

Taking a look at auth0-spa-js it doesn't match our requirements in terms of how tokens are stored, refreshed, etc, and it would be easier for us if the Auth0.js library was updated with PKCE support rather than modifying our entire authentication code to fit the new library.

[luisrudge]

@charsleysa we’re focusing our efforts in the new SDK for now. The discussion on how to move forward with PKCE support in Auth0.js is still ongoing within our team.

Would you mind clarifying what in the new SDK doesn't match your requirements? Thanks!

[charsleysa]

Hi @luisrudge

Thanks for getting back to me.

After taking a further look, I wouldn't say that it doesn't match our requirements but instead that it looks like it does a lot of steps behind the scenes without any control of when they occur.

One example is it looks like you can't create an instance of the Auth0Client without it executing getTokenSilently straight away. We have those two steps separate in our apps workflow so it would require us to come up with a new workflow.

Also, it seems that the library completely controls the storage and lifecycle of the tokens with no way to customize it though I may have missed something here. A migration guide would be handy for clarification and I think most of the issues I see are just loss/handover of control around these steps but there may be good reason for doing so.

Just as an extra (which doesn't greatly affect us but I'll include this anyway) there is a note in the Auth0 Blog about the new library not supporting management / authentication API calls:
In fact, if you still use embedded login or need to call the management API or authentication API, you'll want to stick with auth0.js
Is this because the library is very new and those features will be added in over time, or is there no plan to add support in the auth0-spa-js library?

[luisrudge]

One example is it looks like you can't create an instance of the Auth0Client without it executing getTokenSilently straight away. We have those two steps separate in our apps workflow so it would require us to come up with a new workflow.

Yup! We do that so we can cache the token right away and also so isAuthenticated returns the correct information even if you don't call getTokenSilently.

Also, it seems that the library completely controls the storage and lifecycle of the tokens with no way to customize it though I may have missed something here. A migration guide would be handy for clarification and I think most of the issues I see are just loss/handover of control around these steps but there may be good reason for doing so.

Yes, the idea was to build something that manages the entire authentication lifecycle for you in a very opinionated way, that's why you noticed you have less control and the SDK itself is less extensible. Our goal, of course, is that by giving up some of the control and extensibility, you'll have less code to write and less things to worry about (is my token expired? is the user really authenticated? am I going to hit Auth0's request rate limits?). We wanna make sure that the integration just works without you having to think about it that much.

Just as an extra (which doesn't greatly affect us but I'll include this anyway) there is a note in the Auth0 Blog about the new library not supporting management / authentication API calls:
In fact, if you still use embedded login or need to call the management API or authentication API, you'll want to stick with auth0.js
Is this because the library is very new and those features will be added in over time, or is there no plan to add support in the auth0-spa-js library?

Our plan for the future is to build smaller and more targeted SDKs. You mentioned embedded authentication and the Management API and those are good examples. We're planning to roll out new libraries targeted at those scenarios so developers can pick and choose their libraries accordingly. So, let's say for example you want to use the Universal Login Page + the Management API, you'd install auth0-spa-js and auth0-spa-js-management (fake name).

Since we're still in the planning phase on this, I want to ask you: what do you think about this strategy? Is this something you'd be interested in trying it out?

[charsleysa]

Hi @luisrudge

I like the direction, especially if everything "just works".
We would be interested in trying it out especially if this is the direction Auth0 is wanting to go as it keeps us up-to-date with the latest and greatest.

Just some information about our setup in case this information is useful:

• we operate multiple dashboards (spa web apps) built with Angular 8 and managed using Nrwl Nx workspaces (meaning we can have shared code and app specific code in a monorepo for all our web apps)
• we also have a mobile app on both Android and ios built using NativeScript
• our web apps have two Auth0 clients, one for standard authentication and then another for account linking authentication (using a custom account linking solution on our end, not the Auth0 provided solution)
• we utilize Auth0 sso and silent authentication to achieve seamless authentication across our web apps

Let me know if there's any other information that could be useful!

[luisrudge]

@charsleysa that's perfect. Thanks for sharing! Nativescript might take a while for us to implement, but I believe once we have the management SDK, you'll probably be good to go. The management SDK will probably have the account linking feature as well (using the flow recommended by Auth0), but will also have methods to update your own information etc. You can do that now with raw http requests but we want to make that easier as well. We'll share more on https://community.auth0.com when we have something ready to test. Thanks!

[charsleysa]

https://github.com/sitefinitysteve/nativescript-auth0 😉

In terms of the account linking, we get around the use of management API by using two sets of client credentials with custom rules depending on which client is making the authentication request (and do some server side magic on our side). This is the part where I think we may run into issues with the new library but I'll have a few experiments and see how it goes.

[luisrudge]

https://github.com/sitefinitysteve/nativescript-auth0 this is amazing! Would you be interested in writing a blog post in our official blog about this?

[charsleysa]

Wow, doing an official blog post!? I would love to! Though I'll definitely need a few pointers as Auth0 blog posts are top notch quality!

[luisrudge]

@charsleysa sure! let me ping someone internally to see how can proceed with this. I'll get back to you.

[brunokrebs]

Hey there, @charsleysa.

My name is Bruno and I work on the team that manages Auth0's blog. I'm glad to see that you are up to write about this. We have a Guest Author program in place that can help you promote/talk about this plugin.

Before we proceed though, I will talk to some colleagues and we will take a better look into the plugin (see its correctness and all). I will need a couple of days to do so, but I will ping you here when I'm done, ok?

Thanks!

[charsleysa]

Hi @brunokrebs

That sounds great. The plugin is used in live production apps so having Auth0 look it over to ensure correctness is great!

Let me know if you need anything from me, I'm more than happy to help.

[andreasvirkus]

Would you reconsider supporting PKCE for auth0.js? Reason being that some companies cannot opt for the universal login experience (e.g. custom UI, custom user flows or even if you'd wish to provide both the passwordless and password logins together). If it's then used in a SPA, then without PKCE, there's no truly secure way to grant the client the access token.

Auth0-spa-js is great, but other libraries shouldn't be left behind in feature parity 🙏