Secrets Management

Tokens

» Tokens

Tokens are the core method for authentication within Vault. Tokens can be used directly or dynamically generated by the auth methods. Regardless, the clients need valid tokens to interact with Vault.

As of Vault 1.0, there are two types of tokens: service tokens and batch tokens. The service tokens are persisted; therefore, they can be renewed or revoked before reaching its time-to-live (TTL). On the other hand, batch tokens are not persisted. They are encrypted binary large objects (blobs) that carry enough information for them to be used for Vault actions. Therefore, batch tokens are extremely lightweight and scalable; however, they lack most of the flexibility and features of service tokens.

» Service Tokens vs. Batch Tokens

As the number of machines and apps using Vault for secret management scales, Vault must manage the growing number of client tokens. The creation of service tokens can start affecting the Vault performance since they must be replicated across the primary and secondary clusters. On the other hand, batch tokens are neither persisted to disk nor live in memory, they are not a part of the data replication process.

Depending on the use case and the performance requirements, the batch tokens might work better than the service tokens or vice versa.

» Service Token Lifecycle

Every non-root token has a time-to-live (TTL) associated with it. When a token expires and it's not renewed, the token is automatically revoked by Vault.

When a new token or secret is created, it is a child of its creator. If the parent is revoked or expires, so do all its children regardless of their own TTLs.

Suppose a hierarchy exists with respective TTL as follows:

    b519c6aa... (3h)
        6a2cf3e7... (4h)
        1d3fd4b2... (1h)
            794b6f2f... (2h)

In this scenario, the ID of 1d3fd4b2.. will expire in an hour. If a token or secret with a lease is not renewed before reaching its TTL, it will be revoked by the Vault server. When it's revoked, it takes its child (794b6f2f...) although the child has one more hour before it expires. Then, two hours later, b519c6aa... will be revoked and takes its child (6a2cf3e7...) with it.

» Prerequisites

To perform the tasks described in this guide, you need to have a Vault environment. Refer to the Getting Started guide to install Vault.

» Policy requirements

To perform all tasks demonstrated in this guide, your policy must include the following permissions:

# List available auth method - Step 1
path "sys/auth" {
  capabilities = [ "read" ]
}

# Read default token configuration
path "sys/auth/token/tune" {
  capabilities = [ "read", "sudo" ]
}

# Create and manage tokens (renew, lookup, revoke, etc.)
path "auth/token/*" {
  capabilities = [ "create", "read", "update", "delete", "list", "sudo" ]
}

# For Advanced Features - list available secret engines
path "sys/mounts" {
  capabilities = [ "read" ]
}

# For Advanced Features - tune the database secret engine TTL
path "sys/mounts/database/tune" {
  capabilities = [ "update" ]
}

If you are not familiar with policies, complete the policies guide.

» Steps

This guide demonstrates the lifecycle of service tokens and batch tokens.

  1. Create service tokens with use limit
  2. Periodic service tokens
  3. Renew service tokens
  4. Revoke service tokens
  5. Create short-lived tokens
  6. Orphan tokens
  7. Create batch tokens

Once you understand how to control the token lifecycle, read the Apply Token Types section.

» Step 1: Create service tokens with use limit

In addition to TTL and max TTL, tokens may be limited to a number of uses. Use limit tokens expire at the end of their last use regardless of their remaining TTLs. On the same note, use limit tokens expire at the end of their TTLs regardless of their remaining uses.

To create tokens with a use limit, set the number of uses when you create them.

CLI command / API call using cURL

» CLI command

Create a token with the -use-limit property argument.

Example:

$ vault token create -policy=default -use-limit=2

Key                  Value
---                  -----
token                3B1X9cnfkFYSJh4QS2ma7Cug
token_accessor       1tPKBDUwEi4bt581RoPOXpSi
token_duration       768h
token_renewable      true
token_policies       ["default"]
identity_policies    []
policies             ["default"]

This creates a token with the default policy and a use limit of 2.

» Verification

$ VAULT_TOKEN=3B1X9cnfkFYSJh4QS2ma7Cug vault token lookup
Key                 Value
---                 -----
accessor            1tPKBDUwEi4bt581RoPOXpSi
creation_time       1539822342
creation_ttl        768h
display_name        token
entity_id           n/a
expire_time         2018-11-18T16:25:42.568315198-08:00
explicit_max_ttl    0s
id                  3B1X9cnfkFYSJh4QS2ma7Cug
issue_time          2018-10-17T17:25:42.568315054-07:00
meta                <nil>
num_uses            1
...


$ VAULT_TOKEN=3B1X9cnfkFYSJh4QS2ma7Cug vault write cubbyhole/token value=1234567890
Success! Data written to: cubbyhole/token

# Try to read the value now
$ VAULT_TOKEN=3B1X9cnfkFYSJh4QS2ma7Cug vault read cubbyhole/token
Error reading cubbyhole/token: Error making API request.

URL: GET http://127.0.0.1:8200/v1/cubbyhole/token
Code: 403. Errors:

* permission denied

The first command read the token's properties and then wrote a value to the cubbyhole secret engine. This exhausted the use limit of 2 for this token. Therefore, the attempt to read the secret from the cubbyhole failed.

» API call using cURL

Set the num_uses property in the request payload.

$ curl --header "X-Vault-Token: ..." \
       --request POST  \
       --data '{ "policies": ["default"], "num_uses":2 }' \
       http://127.0.0.1:8200/v1/auth/token/create | jq
{
 "request_id": "c1e1bdf7-1451-a573-7707-27ad587f4481",
 "lease_id": "",
 "renewable": false,
 "lease_duration": 0,
 "data": null,
 "wrap_info": null,
 "warnings": null,
 "auth": {
   "client_token": "3oV2cF9K94Z58gwlnKSPHfu1",
   "accessor": "5ijT5ILtJ5vLupwSwi3eLYYk",
   "policies": [
     "default"
   ],
   "token_policies": [
     "default"
   ],
   "metadata": null,
   "lease_duration": 2764800,
   "renewable": true,
   "entity_id": "",
   "token_type": "service"
 }
}

This creates a token with the default policy and a use limit of 2.

» Verification

$ curl --header "X-Vault-Token: 3oV2cF9K94Z58gwlnKSPHfu1" \
       http://127.0.0.1:8200/v1/auth/token/lookup-self | jq
{
  "request_id": "77be1321-c0ca-e099-6f92-4ad87133b044",
  "lease_id": "",
  "renewable": false,
  "lease_duration": 0,
  "data": {
    "accessor": "4dd5ef0d-8515-c3ae-ea49-016c3e9eb968",
    "creation_time": 1515711922,
    "creation_ttl": 2764800,
    "display_name": "token",
    "expire_time": "2018-02-12T23:05:22.746137253Z",
    "explicit_max_ttl": 0,
    "id": "d9c2f2e5-6b8a-4021-476c-ebd3f166d668",
    "issue_time": "2018-01-11T23:05:22.746136892Z",
    "meta": null,
    "num_uses": 1,
    ...
}

$ curl --header "X-Vault-Token: d9c2f2e5-6b8a-4021-476c-ebd3f166d668" \
       --request POST \
       --data '{ "value": "d9c2f2e5-6b8a-4021-476c-ebd3f166d668" }' \
       http://127.0.0.1:8200/v1/cubbyhole/token


$ curl --header "X-Vault-Token: d9c2f2e5-6b8a-4021-476c-ebd3f166d668" \
       http://127.0.0.1:8200/v1/cubbyhole/token | jq
{
  "errors": [
    "permission denied"
  ]
}

The first command read the token's properties and then wrote a value to the cubbyhole secret engine. This exhausted the use limit of 2 for this token. Therefore, the attempt to read the secret from the cubbyhole failed.

» Step 2: Periodic service tokens

Root or sudo users have the ability to generate periodic tokens. Periodic tokens have a TTL, but no max TTL; therefore, they may live for an infinite duration of time so long as they are renewed within their TTL. This is useful for long-running services that cannot handle regenerating a token.

CLI command / API call using cURL

» CLI command

First, create a token role with a specific period. When you set period, tokens created for this role will have no max TTL. Instead, the period becomes the token renewal period. This value can be an integer value in seconds (e.g.

  1. or a string duration (e.g. 72h).
$ vault write auth/token/roles/<ROLE_NAME> allowed_policies="<POLICY_NAMES>" \
        period=<RENEWAL_PERIOD>

Example:

$ vault write auth/token/roles/zabbix allowed_policies="default" period="24h"

Now, generate a token:

$ vault token create -role=zabbix

Key                  Value
---                  -----
token                1emWvjl6nPVJTmEtu42defWr
token_accessor       5AoOc8UsRM63RrAJZ7LAT9wH
token_duration       24h
token_renewable      true
token_policies       ["default"]
identity_policies    []
policies             ["default"]

» API call using cURL

First, create a token role by setting period. When you set period, tokens created for this role will have no max TTL. Instead, the period becomes the token renewal period. This value can be an integer value in seconds (e.g.

  1. or a string duration (e.g. 72h).

Example:

# API request payload
$ tee payload.json <<EOF
{
    "allowed_policies": [
        "default"
    ],
    "period": "24h"
}
EOF

# Create a token role called 'zabbix'
$ curl --header "X-Vault-Token: ..." --request POST \
       --data @payload.json \
       http://127.0.0.1:8200/v1/auth/token/roles/zabbix

This creates a token role named zabbix with default policies attached. Its renewal period is set to 24 hours.

Now, generate a token:

$ curl --header "X-Vault-Token: ..." --request POST \
     http://127.0.0.1:8200/v1/auth/token/create/zabbix | jq
{
  ...
  auth": {
    "client_token": "45n8ln8azssu4FCCfuEIo4I5",
    "accessor": "23JxEXhFacAdXchuxAHGbt7H",
    "policies": [
      "default"
    ],
    "token_policies": [
      "default"
    ],
    "metadata": null,
    "lease_duration": 86400,
    "renewable": true,
    "entity_id": "",
    "token_type": "service"
  }
}

Generated tokens are renewable indefinitely as long as they are renewed before the lease duration expires.

» Step 3: Renew service tokens

You can renew the service token's TTL as long as it has not been expired.

CLI command / API call using cURL

» CLI command

$ vault token renew <TOKEN>

If you want to renew and extend the service token's TTL, pass the desired extension:

$ vault token renew -increment=<EXTENSION> <TOKEN>

The extension value can be an integer number of seconds (e.g. 3600) or a string duration (e.g. "1h").

» API call using cURL

$ curl --header "X-Vault-Token: ..." --request POST \
       http://127.0.0.1:8200/v1/auth/token/renew/<TOKEN> | jq

# Renew token with 1 hour extension
$ curl --header "X-Vault-Token: ..." --request POST \
       --data '{"increment": "3600"}' \
       http://127.0.0.1:8200/v1/auth/token/renew/<TOKEN> | jq

» Step 4: Revoke service tokens

If a user or machine needs a temporal access to Vault, you can set a short TTL or a number of uses to a service token so the token is automatically revoked at the end of its life. But if any suspicious activity was detected, Vault has built-in support for revocation of service tokens before reaching its TTL.

CLI command / API call using cURL

» CLI command

To revoke a specific token:

$ vault token revoke <TOKEN>

Example:

# Revoke a specific token
$ vault token revoke eeaf890e-4b0f-a687-4190-c75b1d6d70bc

# Revoke all tokens by accessor
$ vault token revoke -accessor 2b2b5b83-7f22-fecd-03f0-4e25bf64da11

» API call using cURL

To revoke a specific token, call /auth/token/revoke endpoint.

Example:

# Revoke a specific token
$ curl --header "X-Vault-Token:..." --request POST \
       --data '{ "token": "eeaf890e-4b0f-a687-4190-c75b1d6d70bc" }' \
       http://127.0.0.1:8200/v1/auth/token/revoke

# Revoke all tokens by accessor
$ curl --header "X-Vault-Token: ..." --request POST \
       --data '{ "accessor": "2b2b5b83-7f22-fecd-03f0-4e25bf64da11" }' \
       http://127.0.0.1:8200/v1/auth/token/revoke-accessor

» Step 5: Create short-lived tokens

Create a new service token with TTL of 60 seconds which means that the token gets automatically revoked after 60 seconds.

CLI command / API call using cURL

» CLI command

To view optional parameters to create tokens:

$ vault token create -help

There are a number of parameters you can set. To specify the token TTL, pass the value using -ttl parameter.

Example:

# Create a token with TTL of 60 seconds
$ vault token create -ttl=60s
Key                  Value
---                  -----
token                HvCymtPxoPaRycY07DeoD32m
token_accessor       44f8d5GR6RhDcMKhhYOMhtoO
token_duration       60s
token_renewable      true
token_policies       ["root"]
identity_policies    []
policies             ["root"]

# Lookup the token details
$ vault token lookup 3b2b1285-844b-4b40-6afa-623f39c1b738
Key                 Value
---                 -----
accessor            3Bsxvo9LEGelKUeHmu67d1Ld
creation_time       1539821459
creation_ttl        60s
display_name        token
entity_id           n/a
expire_time         2018-10-17T17:11:29.372520215-07:00
explicit_max_ttl    0s
id                  3ZJqRqgx9tdBwMQp0CvnVgYH
issue_time          2018-10-17T17:10:59.372520151-07:00
meta                <nil>
num_uses            0
orphan              false
path                auth/token/create
policies            [root]
renewable           true
ttl                 43s
type                service

NOTE: The vault token lookup command returns the token's properties. In this example, it shows that this token has 8 more seconds before it expires.

When you execute a Vault command using the new token immediately following its creation, it should work. Wait for 60 seconds and try again. It returns Code: 403. Errors: which indicates a forbidden API call due to expired token usage.

» API call using cURL

Use the auth/token/create endpoint to create a new token. There are a number of optional parameters that you can pass in the request payload.

Example:

The following example sets the ttl parameter.

# Create a new token with TTl of 60 seconds
$ curl --header "X-Vault-Token: ..." --request POST \
       --data '{"ttl": "60s"}' \
       http://127.0.0.1:8200/v1/auth/token/create | jq
{
  ...
  "auth": {
     "client_token": "5u9HZVxFpCLgMpMuWAkqi6Xf",
     "accessor": "8mp31Ux8HbzNLQ4qJM751w3n",
     "policies": [
       "root"
     ],
     "token_policies": [
       "root"
     ],
     "metadata": null,
     "lease_duration": 60,
     ...
 }
}

# Pass the returned token (`client_token`) in the `X-Vault-Token` header to see its properties
$ curl --header "X-Vault-Token: f7d88963-1aba-64d7-11a0-9282ae7681d0" \
       http://127.0.0.1:8200/v1/auth/token/lookup-self | jq
{
  ...
  "data": {
     "accessor": "7r9C5ENKj8S8s63D7iM53lPU",
     "creation_time": 1539822033,
     "creation_ttl": 60,
     "display_name": "token",
     "entity_id": "",
     "expire_time": "2018-10-17T17:21:33.597621695-07:00",
     "explicit_max_ttl": 0,
     "id": "4NgwZFPWejJJRdY9iHnHhw0C",
     "issue_time": "2018-10-17T17:20:33.59762148-07:00",
     "meta": null,
     "num_uses": 0,
     "orphan": false,
     "path": "auth/token/create",
     "policies": [
       "root"
     ],
     "renewable": true,
     "ttl": 37,
     "type": "service"
 },
 ...
}

When you invoke the API using the new token immediately following its creation, it should work. Wait for 60 seconds and try again. It returns permission denied error.

» Step 6: Orphan tokens

Orphan tokens are not children of their parent; therefore, orphan tokens do not expire when their parent does.

NOTE: Orphan tokens still expire when their own max TTL is reached.

CLI command / API call using cURL

» CLI command

The following CLI command requires root token or sudo capability on the auth/token/create path.

$ vault token create -orphan

» API call using cURL

To create an orphan token, use the auth/token/create-orphan endpoint:

$ curl --header "X-Vault-Token:..." --request POST \
       http://127.0.0.1:8200/v1/auth/token/create-orphan | jq

Also, you can create an orphan token using the auth/token/create endpoint with no-parent parameter set to true.

$ curl --header "X-Vault-Token:..." --request POST \
       --data '{ "no_parent": true }' \
       http://127.0.0.1:8200/v1/auth/token/create | jq

» Step 7: Create batch tokens

Batch tokens are designed to be lightweight with limited flexibility. The following table highlights the difference.

Service Tokens Batch Tokens
Can be root tokens Yes No
Can create child tokens Yes No
Renewable Yes No
Can be periodic Yes No
Can have explicit Max TTL Yes No (always uses a fixed TTL)
Has accessors Yes No
Has Cubbyhole Yes No
Revoked with parent (if not orphan) Yes Stops Working
Dynamic secrets lease assignment Self Parent (if not orphan)
Can be used across Performance Replication clusters No Yes
Creation scales with performance standby node count No Yes
Cost Heavyweight; multiple storage writes per token creation Lightweight; no storage cost for token creation

CLI command / API call using cURL

» CLI command

To create a batch token, you need to explicitly set the token type to be batch.

# Batch token cannot be root.
$ vault token create -type="batch"
Error creating token: Error making API request.

URL: POST http://127.0.0.1:8200/v1/auth/token/create
Code: 400. Errors:

* batch tokens cannot be root tokens

# Attach a non-root policy
$ vault token create -type=batch -policy=test

Key                  Value
---                  -----
token                b.AAAAAQL_tyer_gNuQqvQYPVQgsNxjap_YW1NB2m4CDHHadQo7rF2XLFGdw-NJplAZNKbfloOvifrbpRCGdgG1taTqmC7D-a_qftN64zeL10SmNwEoDTiPzC_1aS1KExbtVftU3Sx16cBVqaynwsYRDfVnfTAffE
token_accessor       n/a
token_duration       768h
token_renewable      false
token_policies       ["test"]
identity_policies    []
policies             ["test"]

Notice that the token value is much longer than the service tokens. This is because batch tokens are encrypted by the Vault's barrier.

$ vault token lookup <batch_token>

Key                 Value
---                 -----
accessor            n/a
creation_time       1539823898
creation_ttl        768h
display_name        token
entity_id           n/a
expire_time         2018-11-18T16:51:38-08:00
explicit_max_ttl    0s
id                  b.AAAAAQKEhArH0qEZze1AHljUq-ujPxQiuZS5VVTrPHtE9mthVu261PpyfcU28StDdLzNBmm5Tf7u5BC3oaiIyUxTxVq1B9SQgnPYnviuWaqlKJ4wzPkQcIyNTg2YdGobdlhaM8AIqbnSPGir5xQnsNRjve48w2c
issue_time          2018-10-17T17:51:38-07:00
meta                <nil>
num_uses            0
orphan              false
path                auth/token/create
policies            [default]
renewable           false
ttl                 767h59m49s
type                batch

Notice that the renewable is set to false.

# Login with batch token
$ vault login <batch_token>

# Batch token has no Cubbyhole
$ vault write cubbyhole/token value="1234567890"
Error writing data to cubbyhole/token: Error making API request.

URL: PUT http://127.0.0.1:8200/v1/cubbyhole/token
Code: 400. Errors:

* cubbyhole operations are only supported by "service" type tokens

# Batch token cannot create child tokens even if its policy grants permission
$ vault token create -policy=default
Error creating token: Error making API request.

URL: POST http://127.0.0.1:8200/v1/auth/token/create
Code: 400. Errors:

* batch tokens cannot create more tokens

# Log in with a highly-privileged token such as root
$ vault login root

# Try to revoke batch token
$ vault token revoke <batch_token>
Error revoking token: Error making API request.

URL: PUT http://127.0.0.1:8200/v1/auth/token/revoke
Code: 400. Errors:

* batch tokens cannot be revoked

» API call using cURL

To create a batch token, you need to explicitly set the token type to be batch.

# Batch token cannot be root.
$ curl --header "X-Vault-Token: ..." --request POST \
       --data '{"type": "batch"}' \
       http://127.0.0.1:8200/v1/auth/token/create | jq
{
 "errors": [
   "batch tokens cannot be root tokens"
 ]
}

$ curl --header "X-Vault-Token: ..." --request POST \
       --data '{"type": "batch"}' \
       http://127.0.0.1:8200/v1/auth/token/create | jq
{
 "errors": [
   "batch tokens cannot be root tokens"
 ]
}

# Attach a non-root policy
$ curl --header "X-Vault-Token: ..." --request POST \
       --data '{"type": "batch", "policies": ["test"]}' \
       http://127.0.0.1:8200/v1/auth/token/create | jq
{
  "request_id": "1f87964f-da70-6ba1-d7a1-fba5d8521e9c",
  "lease_id": "",
  "renewable": false,
  "lease_duration": 0,
  "data": null,
  "wrap_info": null,
  "warnings": null,
  "auth": {
    "client_token": "b.AAAAAQLmvxmoq6RpBNYN-mviYb3fUbIJ4qQ4dIOLpIrQXuL-g376v66MjXYsUyJwDvfN2iK_r5Bx-QppKIp4dJ2-dYhhJOuhbNKWl1NPPUYqU17i-4swgZPPDTe7H3xBcqtl3J0bhhpioLToMN7OwCWPY3LDm5KODhx7tj0",
    "accessor": "",
    "policies": [
      "default",
      "test"
    ],
    ...
}

Notice that the token value is much longer than the service tokens. This is because batch tokens are encrypted by the Vault's barrier.

$ curl --header "X-Vault-Token: <batch_token>" \
       http://127.0.0.1:8200/v1/auth/token/lookup-self | jq
{
  ...
  "data": {
    "accessor": "",
    "creation_time": 1539830790,
    "creation_ttl": 2764800,
    "display_name": "token",
    "entity_id": "",
    "expire_time": "2018-11-18T18:46:30-08:00",
    "explicit_max_ttl": 0,
    "id": "b.AAAAAQLmvxmoq6RpBNYN-mviYb3fUbIJ4qQ4dIOLpIrQXuL-g376v66MjXYsUyJwDvfN2iK_r5Bx-QppKIp4dJ2-dYhhJOuhbNKWl1NPPUYqU17i-4swgZPPDTe7H3xBcqtl3J0bhhpioLToMN7OwCWPY3LDm5KODhx7tj0",
    "issue_time": "2018-10-17T19:46:30-07:00",
    "meta": null,
    "num_uses": 0,
    "orphan": false,
    "path": "auth/token/create",
    "policies": [
      "default",
      "test"
    ],
    "renewable": false,
    "ttl": 2764484,
    "type": "batch"
  },
  ...
}

Notice that the renewable is set to false.

# Batch token has no Cubbyhole
$ curl --header "X-Vault-Token: <batch_token>" \
       --request POST \
       --data '{"value": "1234567890"}' \
       http://127.0.0.1:8200/v1/cubbyhole/token | jq
{
   "errors": [
     "cubbyhole operations are only supported by \"service\" type tokens"
   ]
}

# Batch token cannot create child tokens even if its policy grants permission
$ curl --header "X-Vault-Token: <batch_token>" --request POST \
       --data '{"policies": ["default"]}' \
       http://127.0.0.1:8200/v1/auth/token/create | jq
{
   "errors": [
     "batch tokens cannot create more tokens"
   ]
}

# Try to revoke batch token
$ curl --header "X-Vault-Token:..." --request POST \
       --data '{ "token": <batch_token> }' \
       http://127.0.0.1:8200/v1/auth/token/revoke | jq
{
 "errors": [
   "batch tokens cannot be revoked"
 ]
}


» Apply Token Types

You've learned how you can fine tune the token's lifecycle. Now, let's talk about tokens for your applications. Vault clients first authenticate with Vault using an auth method to acquire a token.

There are auth methods aimed to authenticate applications or machines. Once its identity was verified, Vault server will return a token with appropriate policies attached.

Let's talk about AppRole auth method configuration.

» Generate periodic tokens

To configure the approle auth method to generate a periodic token for your app:

# First, enable approle auth method
$ vault auth enable approle

# Create a role for your app specifying that the generated token should be periodic
$ vault write auth/approle/role/jenkins policies="jenkins" period="72h"

This example defines a role named, "jenkins". The tokens generated for this role will be a periodic token with jenkins policy attached.

» Generate batch tokens

To configure the approle auth method to generate a batch token for your app:

$ vault write auth/approle/role/shipping policies="shipping" \
        token_type="batch" \
        token_ttl="60s"

This example defines a role named, "shipping". The tokens generated for this role will be a batch token with TTL of 1 minute.

» Tune the default TTLs

When you create tokens or leases with no specific TTL values, the default value applies to them.

$ vault auth list -detailed

Path         Type        Accessor                  Plugin    Default TTL    Max TTL    ...
----         ----        --------                  ------    -----------    -------
approle/     approle     auth_approle_9592c1db     n/a       system         system
ldap/        ldap        auth_ldap_38571baa        n/a       system         system
token/       token       auth_token_47eac1f8       n/a       system         system
userpass/    userpass    auth_userpass_6804c90e    n/a       system         system

The system max TTL is 32 days, but you can override it to be longer or shorter in Vault's configuration.

Another option is to tune the mount configuration to override the system defaults by calling the /sys/auth/<METHOD>/tune endpoint.

Read the default TTL settings for token auth method:

$ vault read sys/auth/token/tune

Key                  Value
---                  -----
default_lease_ttl    768h
force_no_cache       false
max_lease_ttl        768h
token_type           default-service

Notice that the token_type is default-service.

» Help and Reference