In an OpenID Connect login flow with the Auth0 OP configured in “OIDC Conformant” mode the ID Token contains the updated_at claim which carries an invalid value type, breaking the login flow against a number of RP implementations (the ID Token carries this claim if the RP requested the scope “profile”, which many RPs do).
That is, the OIDC ID Token emitted by Auth0 does not comply with the OIDC specification and breaks RP implementations, leading to an unsuccessful login flow. This has previously been reported in this forum (updated_at claim has wrong type), but there was no reply.
Reports of the same problem on GitHub:
Roland Hedberg, myself, Michael Schlenker, and others are in agreement that the OIDC spec is unambiguous in this regard, and that the Auth0 implementation violates it. This results in compatibility problems of pretty severe nature: we claim that our product (which uses and OIDC-compliant RP implementation) is fully OIDC compliant, but users of our product complain that it does not work with Auth0.
Especially when turning on the “OIDC Conformant” mode in the Auth0 OP settings the updated_at field must have a value of type JSON number (which is a well-defined type: http://json.org/)
“OIDC Conformant” is currently documented by Auth0 with:
Applications flagged as OIDC Conformant will strictly follow the OIDC specification.
Also on this documentation page you explicitly document that the updated_at claim in the ID Token, if present, has a value of type “number”.
You’re right on all counts; the only issue is that software is complex, it’s written (still mostly) by humans and humans make mistakes.
TL;DR If you have an issue related to updated_at and need it to follow the specification then based on the information I found, for now we can enable a flag in the affected tenants in order for the response to be compliant.
The long story, the service exists before OIDC specification were finalized and when we introduced the admin facing OIDC conformant toggle we missed that updated_at was returning an incorrect type. In other words, technically if we had fixed this when it was found it could technically break customers that were already had enabled the client option but also made the same mistake as us and continued treating updated at as string.
The definitive fix requires a migration and is listed in (Deprecations and Migrations), although it does not yet have a concrete timeline.
If you have a paid subscription you should open a support ticket and tell us the affected tenants; if you don’t have access to support tickets you can DM me the tenant, but this option may be subject to a bit more delays and it depends on me being online.
João, lovely, thank you for the reply.
I understand that you need to be extremely conservative in terms of changing existing environments. Maybe you can introduce another toggle in the admin dashboard titled “OIDC Hyperconformant” ;-).
In any case, I can refer users of our RP implementation to this forum post and suggest to them to reach out to the Auth0 support as you have indicated.
I’m a personal fan of less is more so would be inclined to rename the current one to Almost OIDC Conformant instead of adding a new one, but point taken. At this time I’m afraid that reaching out to our support team (which I’m part of) is what I can offer you with regards to this situation. Ideally I would also prefer not to be in this situation in the first place, but it is what it is.
For the record, Mozilla seems to have worked around that problem at some point with custom code injected via one of the hooks that Auth0 offers. At the core, the workaround uses
context.idToken.updated_at = Math.floor(new Date(user.updated_at)/1000);
See auth0-deploy/temporary-workaround-updatedat.js at a68af4ec9d613b2276b55fb4a9b395fb4f33f943 · mozilla-iam/auth0-deploy · GitHub. This was reported here: oAuth Message Parser expects an int() where a string timestamp is present from Auth0 · Issue #417 · OpenIDC/pyoidc · GitHub – thanks!