[IGN-4521, IGN-4522] Login "fails" when using Auth0 IDP...but not when you retry

I am using Auth0 as my IDP. Most of the time, when logging in to the Gateway, Designer, or a project, I am successfully redirected to Auth0 where I can successfully log in and am redirected back to Ignition. However, when I’m returned, Ignition does not recognize my authentication so I have to log in a second time, but going back to Auth0, reentering my credentials, and then being redirected back to Ignition…again. The second time, however, works great!

Looking through the logs I see several warnings from org.apache.http.client.protocol.ResponseProcessCookies stating:

Invalid cookie header: Set-Cookie: did_compat=...
Invalid cookie header: Set-Cookie: did=...
Invalid 'expires' attribute:...

After all those, the gateway.OIDCWebAuthStrategy logs a warning of:

Unable to retrieve user info from IDP

Searching the web has lead me to think this is an issue with the cookie policy being used by Ignition verses the policy being used by Auth0. Specifically with handling the situation where the cookie has expired. This is why the second time I log in, there is no problem…the cookie I had in my browser the second time was not expired.

What are my options for managing cookie policies with my IDP? Or is there something else going on?

We’ve logged internal tickets to address the “Invalid cookie header” warnings as well as the "Unable to retrieve user info from IDP" error message. The two are completely different issues, and I am not sure if either of them influence the behavior that you mention here:

This just sounds like how most IdP's manage web browser sessions...the first time you have to login, then a cookie is set on your browser so that subsequent visits within a certain period of time will not require logging in again.

The second issue where the user info cannot be parsed is due to Auth0's lack of compliance with the OIDC spec, summarized here: OIDC ID Token claim updated_at violates OIDC specification, breaks RP implementations - Auth0 Community

Specifically, they are returning an updated_at value on the user info response JSON as (what appears to be) an RFC3339 date/time string instead of what the OIDC spec calls for, which is a number representing the number of seconds since the well known 1970 epoch. Sounds like you might be able to talk to Auth0 support and have them toggle a setting on your tenant to switch to the compliant version of that value, which will make the error go away on the Ignition side. We are also going to add code to handle this corner case as well, since there are likely many other Auth0 customers using Ignition and they will likely run into the same issue.

When setting gateway logger gateway.HttpOIDCClientService to level DEBUG or TRACE, the following additional information should appear, which is what lead me to the above conclusion:

INFO   | jvm 1    | 2021/09/24 00:57:04 | D [g.HttpOIDCClientService       ] [00:57:04]: Unable to deserialize the UserInfo from response entity route-group=federate, idp-adapter-name=Auth0_OIDC, route-path=/callback/:type
INFO   | jvm 1    | 2021/09/24 00:57:04 | java.lang.NumberFormatException: For input string: "2021-09-22T20:20:31.323Z"
INFO   | jvm 1    | 2021/09/24 00:57:04 | 	at java.base/java.lang.NumberFormatException.forInputString(Unknown Source)
INFO   | jvm 1    | 2021/09/24 00:57:04 | 	at java.base/java.lang.Long.parseLong(Unknown Source)
INFO   | jvm 1    | 2021/09/24 00:57:04 | 	at java.base/java.lang.Long.parseLong(Unknown Source)
INFO   | jvm 1    | 2021/09/24 00:57:04 | 	at com.inductiveautomation.ignition.common.gson.JsonPrimitive.getAsLong(JsonPrimitive.java:242)
INFO   | jvm 1    | 2021/09/24 00:57:04 | 	at com.inductiveautomation.ignition.gateway.auth.oidc.token.OIDCUserInfo$GsonAdapter.deserialize(OIDCUserInfo.java:416)
INFO   | jvm 1    | 2021/09/24 00:57:04 | 	at com.inductiveautomation.ignition.gateway.auth.oidc.token.OIDCUserInfo$GsonAdapter.deserialize(OIDCUserInfo.java:367)
2 Likes

Tomorrow’s early access build (15 October 2021) should include fixes for these issues.

The second issue (“Unable to retrieve user info from IDP”) will be fixed automatically with no configuration changes.

The first issue (“Invalid cookie header”) can be fixed by setting a system property in ignition.conf - here’s the relevant release note:

Exposed a new system property ignition.http.client.manager.cookieSpec to control the cookie parsing behavior of the IdP and Perspective HTTP Binding’s Http Client. This new system property may take one of the following values:

  • default: Default cookie specification that picks up the best matching cookie policy based on the format of cookies sent with the HTTP response.
  • netscape: This CookieSpec implementation conforms to the original draft specification published by Netscape Communications. It should be avoided unless absolutely necessary for compatibility with legacy applications.
  • standard: Standard CookieSpec implementation that enforces a more relaxed interpretation of the HTTP state management specification (RFC 6265, section 5) for interoperability with existing servers that do not conform to the well behaved profile (RFC 6265, section 4).
  • standard-strict: Standard CookieSpec implementation that enforces syntax and semantics of the well-behaved profile of the HTTP state management specification (RFC 6265, section 4).

If the system prop is undefined or does not match any of the supported values, default value should be default, which is the spec that was used by default in Ignition versions before this system property was exposed.

For Auth0: standard or standard-strict should solve the problem.