x-pack/filebeat/input/{cel,httpjson,internal/dpop}: add support for DPoP OAuth for Okta

[efd6]

Proposed commit message

See title.

Note

This is initially included in the inputs/internal directory. It may be moved in future if it is needed for other packages that cannot see that import path. The API is unstable at this stage, with planned changes (dependent on the json/v2 experiment outcomes).

Note

Claude was used for some code generation in this PR.

Checklist

• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have made corresponding change to the default configuration files
• I have added tests that prove my fix is effective or that my feature works. Where relevant, I have used the stresstest.sh script to run them under stress conditions and race detector to verify their stability.
• I have added an entry in ./changelog/fragments using the changelog tool.

Disruptive User Impact

Author's Checklist

• [ ]

How to test this PR locally

Related issues

• For [Okta]: Support DPoP (Demonstrating Proof of Possession) Header in OAuth2 integrations#15056
• Closes x-pack/filebeat/input/{cel,httpjson}: add support for DPoP OAuth for Okta #47442

Use cases

Screenshots

Logs

[github-actions]

🤖 GitHub comments

Just comment with:

• run docs-build : Re-trigger the docs validation. (use unformatted text in the comment!)

[github-actions]

🔍 Preview links for changed docs

• docs/reference/filebeat/filebeat-input-cel.md
• docs/reference/filebeat/filebeat-input-httpjson.md

[elasticmachine]

Pinging @elastic/security-service-integrations (Team:Security-Service Integrations)

[elasticmachine]

Pinging @elastic/elastic-agent-data-plane (Team:Elastic-Agent-Data-Plane)

[ShourieG]

Since crypto.Signer is now an interface, does it translate back to []byte without any specific method calls ? My concern is for the existing call key, err := pemPKCS8PrivateKey([]byte(pemdata)). Here key eventually translates into the oktaJWT string without any explicit casts or method calls.

[ShourieG]

do we need to do pemPKCS8PrivateKey([]byte(pemdata)).PublicKey() here ?

[efd6]

There's no real change in logic here; the addition at the end is just a safer (non-panicky) assertion, but all the documented returned types from x509.ParsePKCS8PrivateKey except *ecdh.PrivateKey satisfy crypto.Signer. (https://go.dev/play/p/5bvwHEbuuIE) But *ecdh.PrivateKey is not supported by github.com/golang-jwt/jwt/v5, so it's not relevant.

My concern is for the existing call key, err := pemPKCS8PrivateKey([]byte(pemdata)). Here key eventually translates into the oktaJWT string without any explicit casts or method calls.

This cannot be a problem if the returned value from x509.ParsePKCS8PrivateKey satisfies crypto.Signer; the box that holds the value either states that it satisfies crypto.Signer or doesn't say anything (proverbs). The key that's returned is passed into signJWT (as a crypto.Signer) and then on to SignedString as an any, so the path that you are concerned about is entirely untouched.

[ShourieG]

LGTM, from my end