Set up authentication with tokens

Authentication tokens, also known as JSON Web Tokens (JWT), are a method for authenticating Splunk platform users into the Splunk platform. Tokens let you provide access to environments without having to provide the standard types of credentials. Instead of providing a username and password, you provide the token. As a Splunk platform user, you can use tokens to make calls to Representational State Transfer (REST) endpoints and use the Splunk CLI on Splunk Enterprise instances. Tokens are credentials, so you must closely guard them, and not share them with anyone who does not explicitly need access to Splunk platform services.

Authentication tokens are different than other types of tokens you can configure in Splunk Enterprise on forwarders and indexers for authenticated communication between those components, or HTTP Event Collector, though their function is similar.

There are three types of authentication tokens:

• Static authentication tokens let you access a Splunk platform instance. You can create, modify, update and delete them in Splunk Web, and they can last indefinitely.
• Ephemeral authentication tokens are like standard tokens, but you cannot create them in Splunk Web, nor can you modify or update them. They also cannot last for more than 6 hours after you create them.
• Interactive authentication tokens are like ephemeral tokens, but have more restrictions. See the restrictions at How interactive authentication tokens work later in this topic.

As a Splunk platform administrator, you can control a number of authentication token properties for static and ephemeral tokens:

• Who owns the token. A token is associated with a username on the instance
• Token audience. A label that indicates the token's purpose
• How long a token lasts
• When its validity begins. It does not have to become valid immediately when you create it
• Whether or not it is enabled, at any time

You can also delete the token if you no longer want the user to have access through the token. If you disable or remove a token, users of that token lose access to the instance unless they have standard credentials such as the username and password.

Supported Splunk deployment types and authentication schemes for tokens

You can create and assign tokens to various user types that can access a Splunk platform instance, based on the type of authentication system that the instance uses. At this time, tokens are supported in the following deployment types and authentication schemes:

Supported deployment types

• Splunk Cloud Platform instances that are version 8.0.2007 or higher
  • Ephemeral tokens are available in Splunk Cloud Platform version 9.3.2406 and higher.
• Single instances of Splunk Enterprise, on search heads only
• Splunk Enterprise search head cluster nodes

Unsupported deployment types

• Splunk Cloud Platform instances that do not otherwise fit the "supported deployment types" criteria
• Splunk Enterprise Indexers
• Splunk Enterprise Indexer cluster nodes
• Universal forwarders

Supported authentication schemes

• Single Sign-On (SSO) schemes that use SAML. These schemes must either support Attribute Query Requests (AQR) or provide information through scripted authentication extensions
  • On Splunk Cloud Platform, there is support for these schemes and for the Microsoft Azure and Okta identity providers (IdPs) only
• Native authentication
• Lightweight Directory Access Protocol (LDAP) authentication, on Splunk Enterprise only

Unsupported authentication schemes

• Proxy SSO

Prerequisites for activating tokens

Before you activate token authentication in Splunk Cloud Platform, confirm that you have performed the following tasks:

• Configure your Splunk Cloud Platform instance to use the SAML authentication scheme. Currently, Splunk supports using tokens only when Splunk Cloud Platform uses SAML for authentication.
• Configure your Splunk Cloud Platform instance to use a SAML identity provider (IdP) that supports Attribute Query Requests (AQR). Currently, Splunk supports using tokens in Splunk Cloud Platform for the Microsoft Azure and Okta IdPs only. Those IdPs do not support AQR, but do have authentication extensions available. See Configure Splunk Cloud Platform to use SAML for authentication tokens.

Before activating token authentication in Splunk Enterprise, confirm that you have performed the following tasks:

• Enable Transport Layer Security (TLS)/SSL on your Splunk platform instance. See About securing Splunk Enterprise with SSL for details.
• Confirm that you have enabled app key value store (KV Store). By default, KV store is enabled on search heads. See About app key value store in the Admin Manual for more information.

Prerequisites for creating and configuring tokens

Before you create and configure tokens, confirm that you have performed the following tasks:

• Logged in to the Splunk platform as a user that is either an administrator level, such as the sc_admin user on Splunk Cloud Platform, or that holds a role with at least one of the following Splunk platform capabilities:
  • edit_tokens_settings, which turns token authentication on or off
  • edit_tokens_all, which lets you create, view, and manage tokens for any user on the instance
  • edit_tokens_own, which lets you create, view, and manage tokens for yourself
• Completed all of the prerequisites for activating authentication tokens
• Enabled token authentication. See Enable or disable token authentication.

The "list_*" capabilities let you view tokens only

If you have been assigned a role that includes only the following capabilities, you can view tokens, but cannot create them, or enable and disable token authentication:

• The list_tokens_all capability lets you see all tokens on the instance.
• The list_tokens_own capability lets you see your own tokens.

The edit_tokens_* capabilities include the ability to view tokens, as provided by the list_tokens_* capabilities.

How static and ephemeral authentication tokens work

When you create a token, the Splunk platform picks an ID for the token. The token ID references the token information, which the platform stores securely in a KV store collection.

When you use tokens, you must provide the token with each request. If you use the Splunk CLI on Splunk Enterprise, you must supply the token as part of the command or use an environment variable that the CLI picks up. If the Splunk platform uses its native authentication scheme, it does not cache authentication details.

When you present a token as part of a REST request or CLI command, the Splunk platform authentication system does the following:

• It checks to see if token authentication is enabled.
• It processes the token that it receives by validating its signature.
• If checks whether or not the token has expired, or if its validity has not yet started.
• It confirms that the token is available and has not been deleted.
• It checks whether or not the token is enabled.
• It confirms that the user that is associated with the token is authorized to use it.

If all checks pass, it authenticates the user and lets the submitted operation complete.

How interactive authentication tokens work

Interactive authentication tokens work differently than static and ephemeral authentication tokens do.

While the Splunk platform processes interactive tokens for authentication in the same way that it does for static and ephemeral tokens, their creation and configuration aspects are different.

• They are only available for Splunk Cloud Platform
• Your web browser uses them in exchange for a web session cookie that Splunk Cloud Platform gives you when you log in
• They don't take any configuration arguments like the other tokens do
• They last only one hour

Enable, create, manage, and use tokens

See the following topics in this chapter for additional information on how to work with authentication tokens:

• Enable or disable token authentication
• Create authentication tokens
• Manage and delete authentication tokens
• Use authentication tokens