Authentication in Kibana

Basic authentication requires a username and password to successfully log in to Kibana. It is enabled by default and based on the Native security realm provided by Elasticsearch. The basic authentication provider uses a Kibana provided login form, and supports authentication using the Authorization request header’s Basic scheme.

The session cookies that are issued by the basic authentication provider are stateless. Therefore, logging out of Kibana when using the basic authentication provider clears the session cookies from the browser but does not invalidate the session cookie for reuse.

For more information about basic authentication and built-in users, see User authentication.

Token authentication allows users to login using the same Kibana provided login form as basic authentication. The token authentication provider is built on Elasticsearch’s token APIs. The bearer tokens returned by Elasticsearch’s get token API can be used directly with Kibana using the Authorization request header with the Bearer scheme.

The session cookies that are issued by the token authentication provider are stateful, and logging out of Kibana invalidates the session cookies for reuse.

Prior to configuring Kibana, ensure token support is enabled in Elasticsearch. See the Elasticsearch token API documentation for more information.

To enable the token authentication provider in Kibana, set the following value in your kibana.yml:

xpack.security.authProviders: [token]

The token authentication provider can be used in conjuction with the basic authentication provider. The login form will continue to use the token authentication provider, while enabling applications like curl to use the Authorization request header with the Basic scheme. Set the following in your kibana.yml, maintaining the order of the auth providers:

xpack.security.authProviders: [token, basic]

SAML authentication allows users to log in to Kibana with an external Identity Provider, such as Okta or Auth0. Make sure that SAML is enabled and configured in Elasticsearch before setting it up in Kibana. See Configuring SAML single sign-on on the Elastic Stack.

Set the configuration values in kibana.yml as follows:

Users will be able to log in to Kibana via SAML Single Sign-On by navigating directly to the Kibana URL. Users who aren’t authenticated are redirected to the Identity Provider for login. Most Identity Providers maintain a long-lived session—users who logged in to a different application using the same Identity Provider in the same browser are automatically authenticated. An exception is if Elasticsearch or the Identity Provider is configured to force user to re-authenticate. This login scenario is called Service Provider initiated login.

Once the user logs in to Kibana via SAML Single Sign-On, Elasticsearch issues access and refresh tokens that Kibana encrypts and stores them in its own session cookie. This way, the user isn’t redirected to the Identity Provider for every request that requires authentication. It also means that the Kibana SAML session depends on the xpack.security.sessionTimeout setting and the user is automatically logged out if the session expires. An access token that is stored in the session cookie can expire, in which case Kibana will automatically renew it with a one-time-use refresh token and store it in the same cookie.

Kibana can only determine if an access token has expired if it receives a request that requires authentication. If both access and refresh tokens have already expired (for example, after 24 hours of inactivity), Kibana initiates a new SAML "handshake" and redirects the user to the Identity Provider. Depending on Elasticsearch and the Identity Provider configuration, the user might be asked to re-enter credentials.

If Kibana can’t redirect the user to the Identity Provider (for example, for AJAX/XHR requests), an error indicates that both access and refresh tokens are expired. Reloading the current Kibana page fixes the error.

During logout, both the Kibana session cookie and access/refresh token pair are invalidated. Even if the cookie has been leaked, it can’t be re-used after logout. This is known as SAML "local" logout.

Kibana can also initiate a SAML "global" logout or Single Logout if it’s supported by the Identity Provider and not explicitly disabled by Elasticsearch. In this case, the user is redirected to the Identity Provider for log out of all applications associated with the active Identity Provider session.

SAML support in Kibana is designed to be the primary (or sole) authentication method for users of that Kibana instance. However, you can configure both SAML and Basic authentication for the same Kibana instance:

xpack.security.authProviders: [saml, basic]

The order of saml and basic is important. Users who open Kibana will go through the SAML Single Sign-On process unless the direct Basic authentication /login link is used. This might be the case for Kibana or Elasticsearch admins whose accounts aren’t linked to the Single Sign-On users database. Or, when the Authorization: Basic base64(username:password) HTTP header is included in the request (for example, by reverse proxy).

Basic authentication is supported only if basic authentication provider is explicitly declared in xpack.security.authProviders setting in addition to saml.