Thunder's token issuer handling and multi-issuer support

[thiva-k]

This discussion is to address the issues regarding the current token issuer handling in Thunder (#815), and discuss about multi-issuer/authorization server support.

Current Issues

1. Non-Compliant Default Issuer:
   The default configuration in default.json sets jwt.issuer to "thunder". This violates RFC 8414 Section 2, which requires the issuer to be a URL using the https scheme with no query or fragment components.

   "jwt": {
     "issuer": "thunder",
     ...
   }

OIDC discovery relies on appending /.well-known/openid-configuration to the issuer. If the issuer is "thunder", clients cannot construct a valid discovery URL. Furthermore, if the server is running at https://localhost:8090, clients expect the issuer to be https://localhost:8090. A mismatch causes validation failures in standard OIDC libraries such as the Asgardeo SDK and MCP scenarios.

2. Static Configuration Limitations:
   Currently, the issuer is a static string in the configuration. It does not automatically adapt to the server's deployment environment (e.g., changing ports, domains, or running behind a proxy) unless manually updated.

Multi-Issuer Support & Future Considerations

Thunder is planned to have support for multiple issuers/authorization servers. While the current architecture allows for this flexibility (to specify separate issuers at the OAuth-level, application-level, etc.) , we currently do not have concrete use cases driving the implementation and the issues mentioned above are present.

We are looking for community feedback to shape this feature correctly.

Questions for Discussion

1. Ideal Use Cases: What are the primary scenarios where you would require multiple issuers within a single Thunder deployment? Should we support multiple authorization-servers support within a single deployment which binds to each issuer?

2. Domain Binding: How should each issuer be bound to a domain? Should it be path-based (e.g., https://idp.com/iss1) or domain-based (e.g., https://iss1.idp.com)?

3. Certificate Handling: How should signing keys and certificates be managed for each issuer? Should they share a root key, or require distinct keys for each issuer?

4. Discovery & JWKS: How should the .well-known endpoints and JWKS be exposed in multi-issuer scenarios? There should be strictly isolated endpoints per issuer ideally.

CC: @ayshsandu @Thumimku