Add PKC JWKSet reloading to JWT authentication doc

[justincr-elastic]

Doc changes for #88023

• JWT realm now supports reloading PKC JWKs at runtime.
• Use JWKS and UTF-8 keywords consistently.
• Add tip in OIDC JWT section with link to Run-As for dealing with a certain non-OIDC use case.

Doc previews are available for a short time after a build

• https://elasticsearch_88692.docs-preview.app.elstc.co/diff

[elasticsearchmachine]

Pinging @elastic/es-docs (Team:Docs)

[elasticsearchmachine]

Pinging @elastic/es-security (Team:Security)

[lockewritesdocs]

Left some suggested changes, a few of which I took liberty with based on some information that I had trouble parsing. Let me know if I misstated anything. Happy to iterate further!

[lockewritesdocs]

I think that we can reorder this information and split it into two parts to make it flow a bit better:

First part

All other JWT realm validations are checked before a signature failure can
trigger a PKC JWKS reload. If multiple JWT authentication signature failures
occur simultaneously with a single {es} node, reloads are combined to reduce
the reloads that are sent externally.

Separate reload requests cannot be combined in these instances:

• If JWT signature failures trigger PKC JWKS reloads in different {es} nodes
• If JWT signature failures trigger PKC JWKS reloads in the same {es} node, but
  at different times

Second part

This statement is confusing me a bit; I'm not entirely sure what it's referring to:

That way only trusted client applications and realm-specific user JWT will be able to trigger PKC reload attempts.

I'm going to take an educated guess and suggest:

[IMPORTANT]

Enabling client authentication is strongly recommended. Only trusted client applications and realm-specific JWT users can trigger PKC reload attempts. Additionally, configuring the following <<ref-jwt-settings,JWT security settings>> is recommended:

• allowed_issuer
• allowed_audiences
• allowed_clock_skew
• allowed_signature_algorithms
  ====

[justincr-elastic]

LGTM.

If it helps, a more complete view of the order of how settings are used in the code is currently something like this below. Adding complete details would make things too complicated, so it is a balancing act to decide how much detail to put in. The 4 settings you listed above fall into 3-6, and in slightly different order. I don't know if that matters for that you want to achieve, so I will leave it up to you.

1. client_authentication.type (with client_authentication.shared_secret, if type is shared_secret)
2. jwt.cache.size (with jwt.cache.ttl and allowed_clock_skew, if cache is enabled)
3. allowed_issuer
4. allowed_audiences
5. allowed_signature_algorithms
6. allowed_clock_skew
7. validate signature (with allowed_signature_algorithms, and one of pkc_jwkset_path, hmac_jwkset, or hmac_key)
8. if-and-only-if JWT alg is RSA or EC, try reload (or wait if reload is in progress)
9. if-and-only-if reload succeeds and new contents are different, revalidate signature

[lockewritesdocs]

Thanks @justincr-elastic -- I applied these changes in b5a9961.

[justincr-elastic]

@elasticmachine update branch

[justincr-elastic]

@elasticmachine run elasticsearch-ci/part-1-fips

[justincr-elastic]

@elasticmachine update branch

[lockewritesdocs]

@justincr-elastic, it seems that your changes in 8fe00f2 overwrote my changes in b5a9961. I'm unsure if that was intentional or if there was a GitHub collision 💥 Do you want me to reapply that commit?

[lockewritesdocs]

LGTM 🦖 Thanks for iterating @justincr-elastic

[elasticsearchmachine]

💚 Backport successful

Status	Branch	Result
✅	8.4