Auth0 Home Blog Docs

Issue using Lock in SPA for API authorization and MFA



I have a SPA using implicit grant flow to get a token to access a resource API. The problem I have is when enabling MFA (Google Authenticator) it throws an error when it should display the 2FA setup page after the user has entered their username and password into lock. Does anyone know why this would be happening?

Lock 10.13 settings:

var lock = new Auth0Lock(AUTH0_CLIENT_ID, AUTH0_DOMAIN, {
    oidcConformant: true,
    autoclose: true,
    auth: {
        //redirectUrl : 'http://localhost:3000/',					
        responseType: 'token',
        sso: true,
        params: {
            audience: RESOURCE_API_AUDIENCE,
            scope: 'openid'

I’ve noticed if OIDC conformant is enabled then it breaks the MFA enrolment, why is this?

If I do not enable OIDC then the token returned is not in a JWT format which means I can’t validate it on the resource API.

I’ve also just noticed a similar thread on the old forum which outlined this would be supported back in Mar/Apr?


At this time, the use of oidcConformant: true in Lock is not yet documented and as such you should not use it as the lack of documentation also implies the possibility of some behavioral changes. To my knowledge, documentation for this should be coming soon, but don’t take this as a promise. In relation to the specific error I would assume that you’re using username/password authentication with Lock and that explains the limitation you observed when used with MFA; this limitation may not exist in the final documented version.

For now, if you want to leverage user authentication and API authorization in association with MFA my recommendation would be for you to use Auth0.js v8, in particular, the webAuth.authorize method.

As an additional note, the reply in the post you originally mentioned was aimed at support of MFA in the resource owner password endpoint and not in Lock itself. See this for additional information on this; however, for SPA’s the recommendation would still be the one above (Auth0.js v8 with authorize method).


Thanks for responding to my issue.

Do you know when Lock will support oidcConformant?

I have looked at your suggestion of using webAuth.authorize but its unclear from the documentation how this would work in my scenario. Could you provide more details on how i should use the authorize method to achieve my requirements?


I don’t have a definitive timeline, although I can say that the implementation is already consolidated and beyond what you would generally consider the initial stages of feature development. However, there’s much more (docs, etc) then just the implementation itself.

With regards to the possible use of the authorize method, it will depend on a lot of details, but that method redirects to the hosted login page where the hosted version of Lock is shown and user inputs their credentials there instead of directly in your application.


Ok thanks for the update on Lock & oidc.

In terms of the authorize method are you referring to the following:

If I am using a database with ‘Username-Password-Authentication’ then I assume the webAuth.redirect.loginWithCredentialswould be applicable?

The only problem I can see with the hosted login page is that the responses (token) is delivered via the querystring and not in a payload. What should I be using if I want it returned in a payload?


Any feedback on my question? The documentation is not clear on this scenario and is conflicting in areas

Ideally I’d like to be able to have our own login page and receive the auth response via a payload not a querystring. Can you provide direction for this requirement with the context above?


The underlying protocols (OAuth2/OIDC) rely heavily on HTTP redirects so in most situations authentication in a pure AJAX style is not available (assuming you meant AJAX style with delivered in a payload). For some scenarios libraries can abstract the above for you and deliver the response as if it was an AJAX call, but trying to completely avoid redirect-based processes is fighting the protocols you’re using. If you just don’t want the response to be in a query string you can consider the form post response mode.