Non-compliant issuer on https://login-test.signicat.io and https://login.signicat.io

Question:
I just started coding against the test environment for Signicat and ran in to an issue because my OIDC library refuses to configure using the configuration at https://login.signicat.io/.well-known/openid-configuration and https://login-test.signicat.io/.well-known/openid-configuration .

The reason for this is that the issuer field in the configuration lists https://login.idfy.no/ as the issuer, which is different from https://login-test.signicat.io. This is a violation of the OIDC Discovery specification: Final: OpenID Connect Discovery 1.0 incorporating errata set 1 that states

“The issuer value returned MUST be identical to the Issuer URL that was directly used to retrieve the configuration information. This MUST also be identical to the iss Claim value in ID Tokens issued from this Issuer.”

On https://preprod.signicat.com/oidc/.well-known/openid-configuration and https://id.signicat.com/oidc/.well-known/openid-configuration correct issuer values are provided. However, my understanding is that these endpoints are deprecated, and I can’t generate clients for these from the Signicat dashboard.

So far I’m working around this by bypassing OIDC Discovery, but it would be nice if this was compliant so I could use standard libraries for this. For reference, the library I’m trying to use is GitHub - coreos/go-oidc: A Go OpenID Connect client. There is a open issue about this on the library Issuer Name Mismatch · Issue #250 · coreos/go-oidc · GitHub where the library author recommends skipping discovery for non-compliant scenarios.

Answer:

Hi Joakim,

https://login.signicat.io and https://login-test.signicat.io point to the same OIDC instance as https://login.idfy.no and https://login-test.idfy.no respectively. When we added the signicat.io domains we needed our APIs to accept tokens from both hosts, so we let the issuer value remain. Admittedly we did not realize this goes against the OIDC discovery specification, and unfortunately the OIDC library we use did not complain about this.

At this point I don’t know if we can fix this without breaking existing implementations.

As for https://preprod.signicat.com/oidc/.well-known/openid-configuration and https://id.signicat.com/oidc/.well-known/openid-configuration , these are part of our Signicat Enterprise offering which is a seperate solution from our Express offering. They are not deprecated, but requires a wholly different onboarding process.