[FEATURE] usage of JWKS with JWT (without using OpenID connect)

[Rishav9852Kumar]

Description :
An enhancemenet of usage of JWKS with JWT (w/o OpenID connect)
to enable de-coupling between HTTPJwtAuthenticator and HTTPJwtKeyByOpenIdConnectAuthenticator
So this usage of JWKS with JWT could be extended to the JWT backend instaed of OIDC auth backend

What solution would you like?
Extending auth with jwks_uri parameter in JWTs Configuring (inseted of depending on openid in HTTPJwtKeyByOpenIdConnectAuthenticator)

What alternatives have you considered?
#2808

Do you have any additional context?
#2708 (comment) (Moving JWKS completely inside HTTPJwtAuthenticator)

[cwperks]

Thank you for filing this issue @Rishav9852Kumar. For anyone coming across this issue, this is currently possible using the openid backend as outlined in the documentation here: https://opensearch.org/docs/latest/security/authentication-backends/jwt/#using-a-jwks-endpoint-to-validate-a-jwt

This issue is about supporting it directly in the jwt backend as requested in #1858 (comment)

[Rishav9852Kumar]

Ideas :

Traditional Approach : https://docs.opensearch.org/docs/latest/security/authentication-backends/jwt/#using-a-jwks-endpoint-to-validate-a-jwt

Approach 1:

1. Add a boolean isJWKSEnabled in JWT config to add the condition which decides if the validation of the JWT auth token should be done through: Stored public keys, or Use the jwks_url endpoint and (kid in encodedJWT) to get the right public key
2. Add jwks_url as a required parameter for JWT configs if isJWKSEnabled is enabled (where jwks_url is a customer-provided endpoint containing a list of public domains)

Approach 2:

In the auth token of customer request, we check for the (kid in encodedJWT):

1. If found: validate using the jwks_url endpoint and (kid in encodedJWT) to get the right public key
2. If not found: use the default public keys provided in config to validate the token

Questions:

1. Should we fall back to default keys stored in the security config in case the customer-provided jwks_url endpoint is invalid or not working, or fail the auth request?

2. Should we fall back to stored public keys also in case no valid public key is found in jwks_url using (kid in encodedJWT), or fail the auth request?

3. Should both types of config parameters (jwks_url and public key) be allowed, or should a condition be added to allow use of only one?

4. Should both types of config parameters (jwks_url and public key) are provided , which should beprioritized for auth?

[shikharj05]

I am okay with approach 2. Both modes can be supported together - using default public keys + jwks URL. This should help during migrations as well (without downtime). You may consider a set of keys obtained from both sources and validate the JWT token against all such valid keys.

[rursprung]

that sounds a bit weird to have both in the same auth domain. shouldn't you then instead set up two auth domains, one for JWKS and one for the hard-coded key? usually you use JWKS exactly because you don't (want to) have the key. if you support both you risk that users have a mis-configuration where they have both when they only intended one or the other. having two separate auth domains for that setup makes things much clearer

[shikharj05]

that sounds a bit weird to have both in the same auth domain. shouldn't you then instead set up two auth domains, one for JWKS and one for the hard-coded key? usually you use JWKS exactly because you don't (want to) have the key. if you support both you risk that users have a mis-configuration where they have both when they only intended one or the other. having two separate auth domains for that setup makes things much clearer

I don't think security plugin supports setting up two auth domains within the same auth type directly today. If it's supported, I agree these should be two different auth domains. If it does not, this could be a simple way to migrate from one to another and then disable the one not being used. I agree that misconfiguration can lead to unknowns, if a stricter policy is okay - security plugin should allow either JWKS or hard-coded keys.

[rursprung]

I don't think security plugin supports setting up two auth domains within the same auth type directly today. If it's supported, I agree these should be two different auth domains. If it does not, this could be a simple way to migrate from one to another and then disable the one not being used. I agree that misconfiguration can lead to unknowns, if a stricter policy is okay - security plugin should allow either JWKS or hard-coded keys.

it does. we have clusters running with multiple JWTs set up (there's no other way to support multiple signers as the JWT config only supports a single public key).

[shikharj05]

it does. we have clusters running with multiple JWTs set up (there's no other way to support multiple signers as the JWT config only supports a single public key).

Thanks @rursprung! I agree it's better to ensure either JWKS is enabled/used or public key is.