Kanidm: What does endpoint belongs to different authority actually mean?

[TheRealGramdalf]

When attempting to use Kanidm as an identity provider for jellyfin (via OIDC), it throws an endpoint belongs to different authority error. Though mentioned several times (see: Readme, #153, #113, #136), it isn't quite clear to me what this actually means.

I believe it relates to the API path on the IdP used by the resource server (jellyfin). The Kanidm documentation says:

Kanidm will expose its OAuth2 APIs at the following URLs:
- user auth url: https://idm.example.com/ui/oauth2
- api auth url: https://idm.example.com/oauth2/authorise
- token url: https://idm.example.com/oauth2/token
- rfc7662 token introspection url: https://idm.example.com/oauth2/token/introspect
- rfc7009 token revoke url: https://idm.example.com/oauth2/token/revoke

For reference, here's my jellyfin/kanidm configuration:

And the .well-known:

{
  "issuer": "https://auth.domain.tld/oauth2/openid/jellyfin-aer",
  "authorization_endpoint": "https://auth.domain.tld/ui/oauth2",
  "token_endpoint": "https://auth.domain.tld/oauth2/token",
  "userinfo_endpoint": "https://auth.domain.tld/oauth2/openid/jellyfin-aer/userinfo",
  "jwks_uri": "https://auth.domain.tld/oauth2/openid/jellyfin-aer/public_key.jwk",
  "scopes_supported": [
    "openid",
    "profile"
  ],
  "response_types_supported": [
    "code"
  ],
  "response_modes_supported": [
    "query"
  ],
  "grant_types_supported": [
    "authorization_code"
  ],
  "subject_types_supported": [
    "public"
  ],
  "id_token_signing_alg_values_supported": [
    "ES256"
  ],
  "token_endpoint_auth_methods_supported": [
    "client_secret_basic",
    "client_secret_post"
  ],
  "display_values_supported": [
    "page"
  ],
  "claim_types_supported": [
    "normal"
  ],
  "service_documentation": "https://kanidm.github.io/kanidm/master/integrations/oauth2.html",
  "claims_parameter_supported": false,
  "request_parameter_supported": true,
  "request_uri_parameter_supported": false,
  "require_request_uri_registration": false
}

[9p4]

Try pressing the checkbox "Do Not Validate OpenID Endpoints (Insecure)"

[9p4]

This usually means something is misconfigured on the reverse proxy, but it can vary and depends on your setup.

[TheRealGramdalf]

Checking the box does indeed work, but I would still like to know what it actually means if possible.
I'm using traefik as an RP, which terminates SSL/TLS connection with a wildcard cert (*.domain.tld) and connects to Kanidm over SSL/TLS, using Kanidm's self-signed cert. From what I know it could be an SSL/TLS issue, due to multiple certs, or it could be how jellyfin is accessing Kanidm - I have a DNS override that points to the internal IP of traefik, which then proxies the connection to Kanidm. The setup is quite complicated and I haven't quite nailed down some details, so at the moment it's still in flux.

[ToxicMushroom]

Ran into the same issue, but my kanidm instance is not behind traefik TLS stuff, so it probably is unrelated from traefik ? (I do still use it to route tcp with tls pass-trough)

Kanidm does work with mastodon but I also wouldn't call their current implementation a perfect example.

[9p4]

For additional reference: IdentityModel/IdentityModel#456

[Firstyear]

That's a reasonable check for the authority, but it's not checking only the authority, but and entire section of the uri matches the issuer parameter. So perhaps a new issue needs to be raised?

[9p4]

Do you think that the documentation for the plugin ought to recommend turning off the endpoint validation? There is a checkbox for it in the plugin configuration that is on by default.

[Firstyear]

The problem is that the validation is validating "too much". It's validation to enforce that it's the same URI origin is good, but the fact that it expects all the URI to be relative to issuer is the problem here. But if you disable that check (to allow non-relative to issuer URI) you also disable the URI origin verification.

So you could change that in documentation, but I would advise and prefer to see that the validation only check the URI origin is consistent, and not that URI's are relative to issuer. Else a potentially useful security feature is then off by default.

[9p4]

I think this may be something that has to be taken up with IdentityModel

[Firstyear]

I agree, would you like to open the issue with the context here since you are the maintainer of this project?

[9p4]

I believe you would be better qualified to describe the issue and be a liaison with their developers, since you are the one who maintains Kanidm.

[Firstyear]

IdentityModel/IdentityModel#553