To understand the policy, first understand the problem it controls.

The annoyance of signing in again and again

Imagine a company where every employee uses thirty different applications each day: email, chat, calendar, HR tools, ticketing, finance and more. If a person had to type a password and approve a prompt for every single application, they would spend a large part of the day just signing in. People would get frustrated, choose weak passwords, and look for shortcuts. That would be bad for productivity and also bad for security.

Okta solves this by letting a person sign in once and then reuse that proof of identity for a period of time. When the person signs in successfully, Okta creates a session and remembers it, usually by placing a small piece of data called a cookie in the person’s web browser. When the person opens another application connected to Okta, the application sends them to Okta, Okta sees the cookie, recognises the session and says “yes, I already know this person, let them in”. This is the idea behind Single Sign-On.

The danger of sessions that never end

A session is convenient, but it is also a risk. If a session lasted forever, a stolen laptop, a shared computer in a library or a forgotten browser tab could give a stranger access to everything the person can reach. Security teams therefore want sessions to end after a sensible time, and to end sooner when nobody is using them. They also want stronger proof from people who sign in from unusual places. The Global Session Policy is the tool in Okta that turns those wishes into settings.

A short, clear definition before we add any detail.

The plain-language definition

The Global Session Policy in Okta is a set of rules that controls how a user signs in to Okta itself and how the resulting Okta session behaves. It answers questions such as these. Should this person be allowed to start a session at all? Which kind of proof must they give? Must they use a second factor such as a phone prompt? How long can the session last in total? How long can it sit idle before Okta ends it? Should the session survive when the browser is closed?

The word “global” matters. This policy applies to the Okta session as a whole, not to one particular application. Think of it as the main gate of the theme park. What happens at each individual ride is decided by a different set of rules, which we will compare later in this guide.

About the word “Basic”

“Basic” is not the name of a special setting or a separate product edition in the Global Session Policy. In this guide it means the foundation: the simple, essential ideas that you need before moving on to advanced designs. If your organisation uses the word in its own policy names, such as a rule called “Basic”, that is a label chosen by your administrators and you can read its settings like any other rule.

flowchart TD
  A["Person tries to sign in to Okta"] --> B["Global Session Policy is consulted"]
  B --> C{"Which rule matches?"}
  C -->|Allow rule| D["Proof required, then session created"]
  C -->|Deny rule| E["Access denied"]
  D --> F["Session lifetime and idle timers start"]
        

Every field has its own vocabulary. This is the small dictionary for the rest of the guide.

Policy, rule and priority

The relationship between policy and rule is worth fixing in your mind early. A policy is the folder, and rules are the pages inside it. Okta reads the rules from the top of the list to the bottom. As soon as it finds the first rule whose conditions match the person and their situation, it uses that rule and stops looking. This is why the order of rules matters so much.

Okta follows a strict, repeatable routine every time someone signs in.

Step one: find the policy

Every organisation has a default Global Session Policy that applies to everyone who is not covered by a more specific policy. Administrators can create additional policies and assign each to particular groups of people, such as contractors or administrators. Okta checks the person’s group membership, finds the policy that applies, and moves on.

Step two: walk down the rules

Inside the chosen policy, Okta reads the rules in priority order. Each rule has conditions. Typical conditions include whether the person is inside or outside a certain network zone, whether they are signing in through Okta directly or through an external identity provider, and whether Okta considers the sign-in risky. Okta takes the first rule that matches and ignores the rest.

Conditions are the “if” part of every rule.

Each rule begins with conditions that describe the situation it is meant for. The more precise the conditions, the more tailored the experience. Here are the common ones in simple terms.

A practical way to think about it

Try writing each rule as a sentence: “If the person is in this group, and is outside the office network, then require stronger proof and a shorter session.” If the sentence reads naturally, the rule is probably well designed. If the sentence is long and tangled, it is often better to split it into two simpler rules.

The “then” part of every rule controls access and session behaviour.

Allow or deny

The first decision in a rule is whether it allows or denies access. A deny rule is a simple wall: anyone matching the conditions cannot sign in. For example, a company could deny access from a country where it has no staff or customers. An allow rule opens the door and then applies the remaining settings.

The proof required to start the session

An allow rule specifies what proof the person must provide. In the most common setup this means a password, and optionally a requirement for an additional factor. Newer Okta organisations, those running Okta Identity Engine, let administrators tie the session to whichever factors satisfy the application-level requirements, while older Classic Engine organisations present more explicit choices about primary factors and multifactor requirements. The exact wording in the console varies by engine and over time, so always read the labels shown on your own screen.

When to ask for a second factor again

A rule can control how often a person is challenged for MFA. One documented option is to challenge the person again only after an “MFA lifetime” has expired for the device. In that setup the second factor is remembered on the device for a chosen period, and it is enforced when a new session is created or when the person changes devices.

Understanding these two clocks is the heart of the policy.

Maximum Okta global session lifetime

This is the longest a session can last from the moment it starts, even if the person is working constantly. When the lifetime is reached, the person must sign in again. It acts like a hard limit, similar to a day pass that expires at midnight no matter how much fun you are having. Okta offers a choice of how this limit behaves, such as a fixed maximum duration, or settings related to whether the session persists across browser restarts.

Maximum Okta global session idle time

This is how long the session may sit with no activity before Okta ends it. If a person walks away from a computer and nobody touches it for longer than this time, the session expires. It works regardless of the maximum lifetime, so an idle session is cut short even when its total lifetime has not yet been reached. It protects against the forgotten laptop and the shared computer.

sequenceDiagram
  participant P as Person
  participant O as Okta
  P->>O: Sign in with required proof
  O-->>P: Session created
  Note over P,O: Lifetime timer and idle timer start
  P->>O: Opens another app, activity seen
  O-->>P: Idle timer restarts, lifetime keeps counting
  Note over P,O: Person leaves desk, no activity
  O-->>O: Idle limit reached, session expires
  P->>O: Next visit
  O-->>P: Asks to sign in again
        

How the two timers work together

The idle timer keeps restarting whenever Okta sees activity, while the lifetime timer simply keeps counting from the start. The session ends when either timer runs out first. This pairing is clever: it lets a busy person stay signed in comfortably through the day while still guaranteeing that nobody stays signed in forever, and that a walked-away session closes quickly.

What happens to a session when the browser closes is a choice you can make.

By default, many sessions live in a cookie that disappears when the browser is closed. This is called a session cookie. A persistent cookie is different: it is saved to the person’s device and survives closing and reopening the browser, remaining valid until the session expires according to the policy. Allowing persistent cookies makes life easier for people who open and close their browsers often, but it also means the session stays alive on that computer even when nobody is looking at it.

A sensible split

Many organisations turn persistence on for rules that apply to trusted, managed devices and off for rules that apply to outside or untrusted situations. Because rules are checked in order, you can place the stricter rule above the more relaxed one so that risky sign-ins match first.

These two are often confused, so let us separate them clearly.

Okta has more than one kind of policy. The Global Session Policy governs the Okta session as a whole. In Okta Identity Engine there is also an authentication policy (sometimes called an application sign-in policy) that governs the proof required to open each individual application. They work together in layers, a bit like an airport.

flowchart LR
  A["Sign in to Okta"] --> B["Global Session Policy: may a session start, and for how long?"]
  B --> C["Session active"]
  C --> D["Open an application"]
  D --> E["Authentication Policy: what proof does this app need?"]
  E --> F["Access granted to app"]
        

Every organisation starts with a safety net.

Okta provides a default Global Session Policy with a default rule at the bottom, sometimes described as the “everyone” rule. It matches anyone who has not matched a higher rule, so nobody falls through a gap. The default policy is special: some of its conditions are locked, and administrators are limited in how much they can edit them. Typically the settings that can be adjusted on the default rule are the timers, such as maximum idle time and maximum lifetime, rather than the matching conditions themselves.

Why this design is good

A catch-all rule guarantees that every sign-in is handled by some rule. Without it, a person who matched no rule might get unpredictable results. Because the default rule cannot be removed or narrowed, there is always a predictable baseline.

Adding your own on top

The usual approach is to leave the default rule as the safe baseline and add more specific rules above it for special cases. Examples include a stricter rule for administrators, a rule that denies sign-ins from forbidden countries, and a rule that shortens sessions outside the office network.

Administrators hold powerful access, so their sessions can be handled separately.

The Okta Admin Console, where administrators manage users, applications and policies, can have its own session lifetime settings that are independent of the global setting. This makes sense, because an administrator session is far more dangerous in the wrong hands than an ordinary session. A company might allow regular staff a working-day session but ask administrators to sign in more often, with a shorter limit on the Admin Console.

Here is a beginner-friendly plan you can adapt to your own organisation.

An example rule list in words

A policy is only useful if you can see its effects and fix problems quickly.

Security thinking

Session settings are a balance between safety and convenience. Shorter timers reduce the window in which a stolen or forgotten session can be abused, but they can annoy people if set too aggressively. Stronger proof for risky situations reduces the chance that an attacker who has a stolen password can start a session. Denying access from places you never expect sign-ins is a cheap and effective control.

Where to look when something seems wrong

Okta records sign-in and session events in its System Log. When a person says “I keep getting signed out” or “I was not asked for my second factor”, an administrator can search the log for that person’s recent events and see which policy and rule were evaluated, and what the outcome was. This is the fastest way to turn a vague complaint into a precise answer.

Lessons from organisations that have walked this road before.

Good habits

• Order rules from most specific to least specific, with the default rule last.
• Give every rule a clear, descriptive name that explains its purpose.
• Use shorter sessions for administrators and for sign-ins from unfamiliar locations.
• Test every change with a pilot group before applying it broadly.
• Document why each rule exists so future administrators understand it.
• Review policies on a schedule and after any major change such as a new office or merger.

Traps to avoid

Real-world pictures

Short answers to the questions beginners ask most often.

No. Okta does not offer a separate “Basic” edition of the Global Session Policy. The word is best read as “the fundamentals”, or as a label an administrator may have used for a rule.

Not directly. It controls the Okta session. Per-application protection is the job of authentication policies, and the two work together in layers.

Lifetime is the maximum total time a session may exist. Idle time is how long it may sit unused. Whichever is reached first ends the session.

The first matching rule in priority order. After it matches, Okta stops checking the remaining rules.

No. The default policy and its default rule act as the safety net, and only some settings, mainly the timers, can be edited on it.

They may have reached the maximum session lifetime, which ends the session even for busy people. Browser privacy settings can also remove cookies early.

No. A persistent cookie survives closing the browser, but the session still expires according to the lifetime and idle settings of the matched rule.

Yes. The Admin Console session lifetime can be set independently, and a stricter policy can also be assigned to administrator groups.

In the Okta System Log, which records sign-in and session events and helps you see which rule applied.

Apply it to a small pilot group first, verify the behaviour from different locations, keep an administrator recovery path and only then widen the audience.

We started at a theme park with a wristband and ended with a clear picture of how Okta handles sessions. The Global Session Policy is the rulebook for the Okta session: it decides whether a sign-in is allowed, what proof is needed, how long the session can live, how long it may sit idle and whether it survives a browser restart. Rules inside a policy are checked from top to bottom, the first match wins, and a default rule at the bottom keeps everyone covered. Used together with application-level authentication policies, it gives a layered, sensible balance between safety and convenience. Keep the design simple, order the rules carefully, tune timers to risk, and test before you roll out.