Tenant Issuer configuration might not follow the OIDC specification

cthos

I'm not sure if this qualifies as a bug or a documentation issue (or neither), but there's a potential problem with the advice when setting up a tenant.

Under the tenant settings, you set the token issuer - and it advises you to use the FQDN of your domain. The example given is "fusionauth.io". This issuer winds up in the OIDC Autodiscovery config and I believe the "iss" field of the ID Token. So, if you set it to "fusionauth.io" you'll wind up with this:

{
  ...
  "issuer" : "fusionauth.io",
  
}

Issuer, according to the spec (https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata), must include the scheme:

REQUIRED. URL using the https scheme with no query or fragment components that the OP asserts as its Issuer Identifier. If Issuer discovery is supported (see Section 2), this value MUST be identical to the issuer value returned by WebFinger. This also MUST be identical to the iss Claim value in ID Tokens issued from this Issuer.

So, that breaks some OIDC Clients rhat strictly adhere to the spec (I tried it with npm's openid-client but there are likely others).

The spec for the "iss" stanza of ID tokens also needs the scheme: https://openid.net/specs/openid-connect-core-1_0.html#IDToken

Related point, if you use the Tenant's autodiscovery URL, e.g. https://fusionauth.io/{tentant_id}/.well-known/openid-configuration, OIDC clients will generally expect the issuer to include the {tenant_id} as well and try to validate against that. Here's an example from an Okta dev tenant: https://dev-06212286.okta.com/oauth2/ausmf0ocf2mJ2g4Yq5d7/.well-known/openid-configuration

The docs (https://fusionauth.io/docs/get-started/core-concepts/tenants) don't mention any of this - just says FQDN (which does not include a scheme), so while you can configure your Tenant appropriately it's fairly easy to misconfigure it. Might be worth mentioning this somewhere or validating that the issuer (if possible) contains the scheme.

I don't actually know if that was present in earlier drafts of the OIDC spec.