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.

I can't speak to FusionAuth in particular, but when you have a public client you ideally don't want to use the client secret for anything, since SPAs / Mobile Apps / etc cannot keep a secret.

Edit: Found this Github issue marked as wontfix: https://github.com/FusionAuth/fusionauth-issues/issues/2173

If you do need a confidential client for something you should have a separate client for it.

So, my take would be that since you shouldn't be using that secret for anything you shouldn't need it to be required for any flow.

You also didn't ask this but you do want to have PKCE enabled for your SPA's client.

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.