Breaking change in Lock 10.22.0

Help
,
1

I’ve been using a popup login dialog, in a SPA Angular 1 app, for a while.
The code has been a bit like this:

lockProvider.init({
    clientID : AUTH0_CLIENT_ID,
    domain : AUTH0_DOMAIN,
    options : {
        oidcConformant : true,
        autoclose : true,
        auth : {
            responseType: 'token id_token',
            audience: AUTH0_AUDIENCE,
            redirectUrl: AUTH0_CALLBACK_URL,

After accidentally updating to lock v10.22.0 (My bower.json file was set to allow minor updates) this broke for all my users.

There isn’t any mention in the release page, but I’ve seen a response in github to someone else who had the same problem. Essentially, from 10.22.0 the behaviour was changed to forbid the config I’d been using.

This sort of surprise unannounced change is hugely frustrating and disruptive.
(Yes, I know I screwed up by allowing a minor update without realising, but still… this sort of major behaviour change - making what was a working login page into a completely broken login page - doesn’t seem to be a reasonable expectation for an update from v10.21.1 to v10.22.0)

I’ve pinned my dependency to use a pre-v.10.22.0 version for now, until I have time to figure out the new way to implement this.

In the meantime, it might be helpful to update the documentation at Applications in Auth0

Specifically:

The “OIDC Conformant” flag will force
all of these changes at the same time
for a given client, but it’s not the
only option to gradually transition to
the OIDC-conformant authentication
pipeline. Any authentication requests
made with an audience parameter will
use the new pipeline, and all other
requests will continue to work as
usual.

As far as I can see, it’s no longer possible to use the audience parameter if you don’t set oidcConformant to true. If you try you get this error:

It is not possible to use the auth.audience option when the oidcConformant flag is set to false

2

There are a few situations worth mentioning here:

  • formal support for oidcConformant (and audience) parameter in Lock (when embedded in a client application) was only added in Lock 10.22; this situation is document in the reference docs. The oidcConformant flag did already exist in previous versions, but that was part of the ongoing work to support it and there’s a few posts in this community forum warning about this situation and recommending people not use it until it’s formally documented because it could change until the final version and these changes would not be treated as breaking changes.
  • the Lock oidcConformant parameter is only applicable when used embedded in the client application and in this situation you’re correct that you cannot use Lock audience parameter without enabling the other oidcConformant Lock parameter. However, the OIDC Conformant flag that the docs you quoted refer to is the flag at the client settings level. In conclusion, there’s an OIDC flag at the client settings level and there’s also a Lock configuration parameter and they are not exactly the same. If you have a client application that is not using embedded Lock, you can still use the audience request parameter sent to the /authorize endpoint as a way to only have certain requests executed under OIDC conformance (aka not be forced to enable the OIDC client setting flag).
3

Thanks for the reply. Marking as accepted as my post was more a “damn-everythings-broken” rant than an actual question.

The problem with saying that the oidcConformant was only just added is that it has been in the sample since April and is still there now.

This, and any apps like mine that were based on it, are now broken.

4

That is indeed bad and on us for providing a faulty sample. At one point in time an internal discussion called the attention to the fact that the sample was slightly ahead of the official support in Lock, but it was not changed because we were expecting to update the documentation and provide final support soon after (matter of days). However, as frequent with software development dates were pushed farther and I honestly forgot to continue to push for the review/removal of that sample (my bad). Nonetheless, I’ll relay your feedback internally as a lesson learned. Apologies for this.