Any interest in API authentication without long-lived secrets or having to configure/retrieve public keys?

Elastic Search
1

Hi all,

Elasticsearch is already very flexible when it comes to client authentication, but the options that are natively supported fall under two categories:

  • Long-lived, shared secrets, which can be cumbersome when adopted securely -- and a liability when not.
  • External authentication methods, all of which require the trusted keys/certificates to be configured upfront (i.e. the PKI method) or retrieved during verification (JWT and all the other methods). Yet configuring the trust store upfront introduces operational complexity, and retrieving the public keys or certificates on demand introduces reliability issues.

Kliento others a third option. Its credentials, known as token bundles, are short-lived and contain the entire chain of trust (anchored in DNSSEC). They're like JWTs that can be verified 100% locally without configuring or retrieving public keys (unlike JWTs).

Kliento is a tiny extension to VeraId, which has been independently security audited and has an Internet-Draft. The protocols have open source reference implementations.

If there's enough interest, I'd be happy to build a custom realm so you can see it in action in Elasticsearch and then reimplement it properly if there's enough demand. It'd work like this:

  • No upfront configuration: Just enable the custom realm.
  • For each client, just register their identifier. This will be a string like your-app@your-domain.com, your-app@staging.your-domain.com, your-domain.com, etc.
  • The client has two options to obtain token bundles:
    • By exchanging its platform's credentials. That is, if your client runs on GitHub, Kubernetes, GCP, Vercel, or many others, you could obtain the credentials directly via an app we provide, which can be run on-prem or in the cloud.
    • By generating the credentials directly, if you're happy to manage a private key.
  • Once the client has a token bundle, it'd just have to include it in the Authorization request header. Such bundles are valid for a maximum of 60 minutes (configurable) and can be reused whilst they're valid.

With that in mind, would this be something you'd be interested in? Any questions or concerns?

Thanks!

Gus.

2

This is a compelling concept. Managing trust stores and long-lived secrets at scale is a known pain point, especially in dynamic environments like Kubernetes or multi-cloud platforms.

The idea of DNSSEC-anchored, short-lived, self-contained token bundles is quite powerful — eliminating the need for preconfigured trust anchors or external JWKS fetches could simplify client auth flows significantly.

I’d be very interested in seeing how this would integrate with Elasticsearch's realm architecture, especially in terms of token parsing, caching, and support for multi-tenant scenarios. A prototype realm would be great for evaluation.

Looking forward to updates on this.