OpenID Connect support

:bulb: OpenID Connect Support

Idea description

OpenID Connect has become the de facto authentication protocol in the web, and is being quickly adopted by the enterprise as well. It may be possible to create something via a smart reverse proxy and JWTs, but it would be great if ReadonlyREST had native support for OIDC.

:eyes: Example

  1. Authenticating against web-based IdP like Google, Facebook, Auth0, …
  2. Authenticating against a standard compliant on-premise IdP like Keycloak or Gluu Server

Hey @took! I agree this would be a very nice feature to have.
I assume you mean we support this in the Kibana plugin, right?

I think authentication is applicable both to GUI based usage & API based usage.

  • For Kibana GUI, the canonical way would be to trigger authorization code flow to authenticate the user, and pass the acquired access token to ElasticSearch API as a bearer token. Token refresh for longer sessions would need to be managed as well.
  • For ElasticSearch API, the access token should be verified. Usually this is passed as a bearer token. The token could come from Kibana, or from API user who acquired it using one of the standard flows.

Standard defines the access token opaque, in practice the token may be a JWT in which case there’s no need to contact the IdP for introspection as it can be verified cryptographically. If token is not JWT, it needs to be passed to IdP introspection API. The token type depends on the issuing IdP.

In OIDC, access token can be used to get a JWT known as ID token, which contains then the actual user information, and quite often additional claims like groups.

1 Like

In principle using existing JWT support I think one could put an external reverse proxy like nginx in front of both Kibana & ElasticSearch and manage the OIDC flows & token refresh there, passing the ID token as a JWT to Kibana or ElasticSearch, respectively. It’s doable with e.g. GitHub - zmartzone/lua-resty-openidc: OpenID Connect Relying Party and OAuth 2.0 Resource Server implementation in Lua for NGINX / OpenResty but requires securing the transport to only allow access through nginx to the endpoints, and takes some understanding of how the protocol works to configure correctly :slight_smile:


OK, so to summarise:

  • ES side: we need a rule that reads tokens from Authorization header, and exchanges it with a ID token (JWT format) from a configured identity provider.

  • Kibana side: the full authentication to be resolved within Kibana and the identity shall be forwarded to ES using the JWT bridge we have in place for SAML.

I think it’s important that Kibana handles the whole flow on its own for two reasons:

  1. We can use ready made library (TBD).
  2. We don’t want to force people to expose Elasticsearch HTTP API to the external network, they are already exposing Kibana.

Looks good to me. I’d expect to see at least the following config parameters:

  • Client ID
  • Client secret
  • OIDC discovery URL

Rest of the OIDC related parameters could be fetched from the discovery URL.

1 Like


Would be a much appreciated feature.
Especially on the ElasticSearch plugin.
Our university provides several data sets via ElasticSearch,
Some of them open but most of the indices are closed/protected.
At the moment a server web application which is secured via SAML
or OpenID Connect accesses the ElasticSearch cluster with a service account.
If web apps (no intermediate server) could access certain ElasticSearch indices
with the OpenID connect flows, this would be perfect.


We are in the process of refactoring our Enterprise plugin so adding multiple SAML identity providers or new auth protocols like OpenID connect will be possible.

Update on this:

  • Multiple SAML providers feature is generally available
  • Interoperability with Keycloak via SAML works as a charm and we have documented how to do it.
  • OpenID Connect is next

Any news on OpenID Connect support?

Or maybe you have a manual for integrating with existing external keycloak for SAML?
The only manual I could find ( says “just import this config and don’t bother” but it don’t work with external keycloak.

hi @DarthSlider, we could make your Keycloak work. What’s the problem? (let’s open another topic though!)

@jdc, @took, @DarthSlider we have OIDC working in an experimental build, interested in trying it? I just tested it against Keycloak and it works.