Adding JWT auth capability for s2s replication

[stuart-wells]

What changed?

Adds JWT to server-to-server connections. Frontend already had support for reading auth so this focuses on getting a token and injecting it.

Why?

s2s is currently a gap in the auth abilities. This provides more flexibility for users based on their auth requirements.

How did you test it?

• built
• run locally and tested manually
• covered by existing tests
• added new unit test(s)
• added new functional test(s)

Potential risks

Need to get auth right. Main risk is a user believing they are secure when they are not.

[dnr]

I haven't looked in detail at this code yet, but one feature that's been requested a lot is to be able to authenticate internode connections (within one cluster) with tokens instead of mTLS. Would it be easy to cover that use case in this PR as well?

[dnr]

Also, for frontend auth, we have this pluggable ClaimMapper interface that defines how tokens/TLS info is handled, and then a JWT-based implementation. Can we set up something similar (or reuse ClaimMapper) so that s2s (and internode) token-based auth isn't tied to JWT either?

[stuart-wells]

@dnr If it's just one auth provider being used to authenticate internode and cross-cluster connections, this implementation should just work (From the TokenProvider plugin side. I figure and Authorizer or ClaimMapper changes for the Internal Frontend/ClaimMapper would be separate). There might be improvements for that usecase but it wouldn't be far off.

Re not being JWT-specific - good point. I went back and moved some of the JWT logic out of the config and tried to make it more generic. So the TokenProvider plugin should be usable by non-JWT setups. I've only been testing for JWT since that's what we currently explicitly list in the ClaimMapper docs though.