Hi,
We are currently using the auth0-spa-js package in our React project and it works quite nice with the Universal Login and we would like to keep it. But we now have the problem that we also need to provide a custom UI login which unfortunately currently is not possible with auth0-spa-js. This is why we needed to go back to the auth0-js package to use the co/authenticate endpoint but there we faced the problem that it doesn’t support the PKCE flow.
However, in some tests we did we were able to achieve our goal with a combination of auth0-js and auth0-spa-js, but it was necessary to make some changes to the code of auth0-js in order to store the audience, scope and code_verifier in the transaction (so that the flow used by auth0-spa-js can retrieve the correct values from the transaction cookie and verify the code).
Now, having to use two packages in order two handle two different parts of the login flow is not the best solution but that was the only way for us to use the convenience of the auth0-spa-js package and the PKCE flow and also to be able to offer a custom UI for our login.
Are there any plans to either support the custom UI login in auth0-spa-js or to enable the PKCE flow in auth0-js?
(The main changes we did in src/web-auth/transaction-manager.js in the process respectively the generateTransaction method in order to store the audience, scope and code_verifier from the options object in the transaction. Also, we needed to delete the code_verifier from the params object in the authorize() method in order to get rid of the warning that the parameter code_verifier is not allowed in the authorise endpoint. With this changes the we were able start the login with auth0.WebAuth from the auth0-js package with the following call:
auth.login(
{
realm: 'Username-Password-Authentication',
email,
password,
code_verifier: verifier,
code_challenge: challenge,
code_challenge_method: 'S256',
},
callback
);
Then we handle the response with Auth0Client handleRedirectCallback from auth0-spa-js.
So basically for us it would be sufficient if the auth0-js package would store these additional fields in the transaction).
1 Like
Hi @chrstnkl,
and it works quite nice with the Universal Login
Are you using the New ULP (Universal Login Page) or the Classic? (which you select under Dashboard > Universal Login Page)
Are there any plans to either support the custom UI login in auth0-spa-js
This would need to be answered by someone from the SDK team.
or to enable the PKCE flow in auth0-js ?
It’s not planned, because that’s what the new SPA JS SDK supports, which should be seen as a replacement for the older auth0.js (though obviously not everything the auth0.js could do is yet covered).
we faced the problem that it doesn’t support the PKCE flow.
Am I right to assume that the reason you need PKCE is because the Implicit Flow with enough risk mitigation on your client application side isn’t sufficient for you? (Basically referring to this blog post here: OAuth2 Implicit Grant and SPA)
Hi @mathiasconradt,
Are you using the New ULP (Universal Login Page) or the Classic? (which you select under Dashboard > Universal Login Page)
Yes, we are using the new ULP. But the question to use PKCE or the implicit flow shouldn’t be dependent whether we’re using the new or the classic login page, should it?
This would need to be answered by someone from the SDK team.
It’s not planned, because that’s what the new SPA JS SDK supports, which should be seen as a replacement for the older auth0.js (though obviously not everything the auth0.js could do is yet covered).
That’s why it would be cool if the embedded login for creating a custom UI would also be support it in the auth0-spa-js package.
Am I right to assume that the reason you need PKCE is because the Implicit Flow with enough risk mitigation on your client application side isn’t sufficient for you? (Basically referring to this blog post here: OAuth2 Implicit Grant and SPA)
Yes, you’re right.
1 Like
But the question to use PKCE or the implicit flow shouldn’t be dependent whether we’re using the new or the classic login page, should it?
Yes, that’s right. My question was because: if you’d use the Classic hosted page, you could use both the Aut0 standard out-of-the-box Lock but also a Custom UI hosted on Auth0 end (if/else login based on i.e. clientId), not needing to embed it in our client application (unless you have other requirements that wouldn’t allow for this), and then also not needing to use the auth0.login() / username-password-authentication realm.
But if you’re using the New ULP, this couldn’t be considered anyways. And I assume you also have other reasons why you’d need it embedded.
When can a response be expected? Is there a better way to get in contact with them beside this forum?
When can a response be expected? Is there a better way to get in contact with them beside this forum?
You can also put it as a feature request in Github: Issues · auth0/auth0-spa-js · GitHub