Capability

Short-lived tokens

What it does: Tokens expire fast, and refresh tokens rotate.

WIC

In short

Short-lived tokens expire after a limited time that you set, so a stolen token is useful to an attacker only for a short window. Token lifetimes and global session policies set the maximum time access can last, including when refresh tokens renew access.13

Book a callHow Okta does it ↓
4
attack types it helps against

What it is, and the attacks it stops

After a user signs in, apps rely on tokens and sessions instead of asking for the password again. Whoever holds a valid token can act as the user until that token expires.

Short-lived tokens limit that window. Okta can issue tokens with a limited lifetime and renew them through refresh tokens, but global session policies still cap how long a user can stay signed in overall.123

That limits the damage from attacks such as:

1

Stolen session cookies and tokens

Malware on a laptop copies a token from the browser. A short lifetime shortens the time the attacker can use it.

2

Adversary-in-the-middle session theft

A proxy captures the session after the user completes MFA. A token that expires soon gives the attacker less time to work with it.

3

Tokens leaked in logs or code

A token ends up in a log file, a ticket or a repository. If it has already expired, the leak is not very useful.

4

Access that outlives a leaver

An employee leaves, but a long-lived token keeps working. A short lifetime closes that gap sooner.

Before and after rollout

Without
With
WithoutA stolen token keeps working indefinitely.
WithA stolen token stops working after the lifetime you configured.1
WithoutOne long-lived refresh token can be copied and reused again and again.
WithWith refresh token rotation, a new refresh token is issued each time one is used.2
WithoutEach app decides on its own how long a sign-in lasts.
WithSession and token lifetimes are set centrally in Okta policies.3
WithoutAfter someone leaves, nobody knows which tokens are still valid.
WithAccess token, refresh token and Okta session limits together set how long access can last, while app sessions need their own limits or Universal Logout.13

How Okta does it

Okta gives you several settings that control how long a sign-in stays valid. You can use them together.

1

The user signs in once

The user signs in to Okta, which starts a session for single sign-on.3

2

Okta issues tokens with a limited lifetime

Okta issues access tokens to the app, and you configure how long they stay valid.1

3

The app renews the token when needed

The app can use a refresh token to get a new access token without asking the user to sign in again.2

4

Policy decides how long renewal is allowed

Session and token settings in Okta determine when the user has to authenticate again.13

WIC
Who it protectsStaff, contractors, admins
Access token lifetimeOn an Okta authorization server, you can configure how long access tokens stay valid.1
Refresh token rotationOkta supports refresh token rotation, which issues a new refresh token each time one is used.2
Global session policiesGlobal session policies in Okta set maximum session lifetime and idle timeout, which cap how long access can last even when tokens refresh.3

How Zelto implements it

Okta provides the settings - Zelto agrees the values with you, because a lifetime that is too short breaks apps and one that is too long defeats the purpose. We plan changes in groups to minimize risk/impact. We start with the apps that hold the most sensitive data.

Typical rollout

  1. Map which apps hold tokens and for how long

    We list your apps, how they get tokens and how long those tokens live today.

  2. Set target lifetimes by risk

    We propose shorter lifetimes for apps with sensitive data and admin tools. Lower-risk apps keep a longer lifetime so users are not interrupted.

  3. Pilot with one app and its owner

    We change one app first and agree with its owner on what counts as a problem and when to roll back.

  4. Roll out one app at a time

    We change the lifetimes app by app in Okta. Your help desk gets a script for the questions users will ask about being signed out.

  5. Test leaver and revoke paths

    We check what happens to access when someone leaves or a device is lost, and we repeat that check on a schedule.

Pitfalls we plan for

Tokens are shortened and users are signed out all day.

−Lower every lifetime at once, and users start asking for exceptions.

+Set lifetimes per app by risk, pilot them with one app first, and adjust before rolling out wider.

A short access token is paired with a refresh token that never expires.

−Keep long-lived, non-rotating refresh tokens, so an attacker who steals one keeps access.

+Turn on refresh token rotation where the app supports it, and agree on a maximum refresh lifetime per app.

An employee leaves and their sessions are still open.

−Wait for the tokens to expire on their own.

+End the session and revoke tokens as part of the leaver process, and test that step on a schedule.

Integrations and scripts use static API keys that never expire.

−Shorten user tokens and leave the static keys in place, so attackers go after the keys instead.

+List every static key, assign an owner, and move to short-lived tokens where the integration allows it.

Want tokens that expire on purpose, without users being signed out all day?

We review how long your sessions and tokens live today. Then we tell you which apps to change first.

Book a call30 minutes, no slides. We look at how your apps handle sessions and tokens today.

Related blog posts

Notes from rollouts

D is for DeprovisioningRead on the blog →

Sources

Official Okta and Auth0 documentation and primary legal sources.

  1. 1OAuth 2.0 and OpenID Connect overviewdeveloper.okta.com
  2. 2Refresh access tokensdeveloper.okta.com
  3. 3About global session policiesOkta Help Center