Allow better control for discovery endpoints to use

[marchchad]

Checklist

• I have looked into the Readme and Examples, and have not found a suitable solution or answer.
• I have searched the issues and have not found a suitable solution or answer.
• I have searched the Auth0 Community forums and have not found a suitable solution or answer.
• I agree to the terms within the Auth0 Code of Conduct.

Describe the problem you'd like to have solved

I'm setting up an express js API to verify tokens issued by a Keycloak v23 instance. Keycloak provides a /.well-known/openid-configuration endpoint but does not publish a /.well-known/oauth-autorization-server endpoint. When using the express-oauth2-jwt-bearer package, it took me reading the source code to see that the only way to use the package was to provide the full url to the well known endpoint so it could short circuit the asserts here: https://github.com/auth0/node-oauth2-jwt-bearer/blob/main/packages/access-token-jwt/src/discovery.ts#L31. Otherwise the package also attempts to fetch the oauth-authorization-server endpoint, which isn't available on Keycloak: https://github.com/auth0/node-oauth2-jwt-bearer/blob/main/packages/access-token-jwt/src/discovery.ts#L43-L47

Describe the ideal solution

There's multiple solutions to this problem:

• Improved documentation for use in different auth scenarios, such as OIDC only providers
• Configuration Option / Environment Variable to specify OIDC, OAUTH, or BOTH. Could even default to both, but provide option to only attempt to discovery of one of the 3 scenarios
• Don't fail initialization if both aren't available. Attempt discovery and verification of both endpoints, fail it both are unavailable, but log a warning if one of the two are not available

Alternatives and current workarounds

The current workaround is to specify the full URL to the /.well-known/openid-configuration endpoint. As far as I can tell, this configuration option is not documented.

Additional context

No response

[marchchad]

I forgot to specify, but the error I was receiving is the error specified in #132

InvalidTokenError: Failed to fetch authorization server metadata

[arpit-jn]

Hi @marchchad 👋

Thanks for the detailed report on the Keycloak discovery endpoint issue. You've hit on a really important point about making our library more flexible for different identity providers.

There are a few ways we could tackle this, and I'm keen to get more input from the community. Hence, I'd like to move this over to our Discussions section.

1. Enhancing documentation: We could provide clearer guidance on using the full URL workaround.
2. Adding configuration options: We could introduce a way to specify which discovery endpoints to use.
3. Modifying behavior: We could change the library to succeed if at least one endpoint is available.

Before we make any changes to the core library, it would be great to hear from other users about their experiences with various identity providers. This will help us land on a solution that works broadly.

Could you share a bit more about your Keycloak setup in the discussion? Any extra details about your configuration would be super helpful as we design a fix.

In the meantime, the workaround you've already found (using the full URL to the discovery endpoint) is definitely the way to go.

Thanks again for bringing this to our attention.

[marchchad]

Hey @arpit-jn

Thanks for picking this up.

I think no matter what enhancing the documentation should be a step taken and can be a separate task since it can be done quickly and cover the current state of the package.

In regards to the hesitation to not modify the core library, I'm curious what identity providers (IdPs) this was developed against that published both oidc and oauth2 discovery points and the design decision(s) for this package to assume both when just providing a root domain of the IdP.

As for the keycloak setup that I was working on at the time I ran into this issue, it's pretty basic. A single realm with a handful of users that we're managing for a test site. I have other configurations that are more robust, but no matter how simple or complex, that doesn't change what discovery endpoints are published. I think the key here is that although oauth2 clients can use the OIDC endpoint, this package is assuming that both are going to be made available and there's no documentation or runtime warnings/errors that provide the user of this package any indication as to what the package is looking for; the error referenced earlier is not helpful. It's a fine start, but since this isn't an error that can bubble up to an end user, it's perfectly fine to reveal to the developer further information as to what value(s) the package was evaluating and what it was expecting when returning the error.