Start with three plain ideas: a session, a policy, and the word global.

A session is a period of trust. When you sign in to Okta and prove who you are, Okta remembers that proof for a while, so you do not have to type everything again every time you open another app. That remembered period is your session. It usually lives in the browser as a small piece of data called a cookie.

A policy is a set of rules. Each rule looks at a situation, such as who the person is and where they are, and says what should happen. A global session policy is the set of rules that governs how Okta creates and manages the session for signing in to Okta itself. The word global means it applies to the sign-in to the whole Okta account, not to a single application.

In short, the global session policy answers three questions. Who may open a session? What proof must they give to open it? And how long may the session last before Okta asks again?

Three questions this guide answers

Everyday phrases and what they really mean

Identity teams use short phrases that confuse newcomers. When someone says “the session expired”, they mean Okta stopped trusting the earlier sign-in and wants new proof. When they say “step up”, they mean a person already signed in is asked for a stronger proof. When they say “idle timeout”, they mean the session ended because nothing happened for a while. Knowing these three phrases makes most documentation easier to read.

A session is convenient, but a session with no limits is dangerous. Rules exist to find the balance.

Imagine signing in to Okta once and staying trusted forever. That would be wonderfully easy, and wonderfully risky. A laptop left on a train, a stolen cookie, or a shared computer could give a stranger full access for weeks. On the other side, asking for a password and a second proof every five minutes would drive everyone mad.

The challenge is that people are not all the same, and situations are not all the same. An administrator who can change security settings deserves tougher rules than someone who only reads the cafeteria menu. A sign-in from the head office is less suspicious than one from a country the company has never worked in. Policies let you write these differences down once, and apply them every time.

What goes wrong without clear rules

Why this matters even for small teams

Some teams believe session rules are only for large enterprises. In truth, the questions begin the day a company has two kinds of users, such as staff and contractors, or two kinds of devices, such as laptops and shared tablets. A small clinic whose staff share one reception computer faces the same puzzle as a large factory, only on a smaller scale. Writing down the rules early costs an afternoon. Untangling a rushed setup after it has spread to hundreds of people costs months.

The habit is cheap to start. List your groups of users, note what devices each group uses, and mark the most sensitive roles. That one page already shows where a single default rule will do and where a dedicated policy is worth the effort. It also prepares you for audits, mergers, and new regulations, all of which ask the same basic questions.

A short vocabulary list makes the rest of this guide much easier to follow.

Session management has its own words. Most describe either what is being checked, or how long trust lasts. The table below puts each term next to a simple picture.

Policy, rule, condition, action

These four words build the whole structure. A policy contains rules. Each rule has conditions, which are the facts it checks, and actions, which are the things it does. Okta reads the rules in order, finds the first one whose conditions match, and applies its actions. Once you hold this picture in mind, every screen in the console makes sense.

Authentication and session are different

Authentication is the act of proving who you are. A session is the memory of that proof. A person authenticates once, and the session carries that result forward. The global session policy sits at the border between the two. It decides how authentication must happen, and then how long the resulting session may be trusted.

Common misunderstandings

Before writing rules about sessions, understand what a session really is under the hood.

When you finish signing in to Okta, the service creates a session record on its own servers. It also hands your browser a cookie, a small secret value that points to that record. Each time your browser visits Okta again, it sends the cookie along. Okta looks up the record and says “yes, this person already proved who they are”.

This design has two important consequences. First, whoever holds the cookie holds the session, so protecting it matters. Second, the session lives on Okta’s side too, which means Okta can end it at any time, even if the browser still holds the cookie.

The clocks that run inside a session

How the clocks combine

The two main clocks work together. The idle timer resets every time the person does something. The lifetime timer never resets. A person who keeps working all day will not hit the idle limit, but will still meet the maximum lifetime eventually. A person who walks away for lunch may hit the idle limit long before the lifetime ends.

Two policies often work on the same sign-in. Knowing which does what avoids the most common confusion.

The global session policy governs the sign-in to Okta and the session that results. An authentication policy, in contrast, is attached to a particular application. It says what proof is needed to open that application, even for a person who already has a session. In Okta Identity Engine, both policies are evaluated, and the stricter demand wins.

How they work together

Here is the full picture of how a person, the policy, and the session fit together.

The design has a few clear parts. The person tries to sign in from a browser on some device and network. Okta gathers facts about that attempt, such as the person’s groups, the network zone, and the proofs available. The global session policy compares those facts with its rules. The result is either a denial, or a session with specific proof requirements and time limits.

flowchart LR
  subgraph UserSide["User Side"]
    P["Person"]
    B["Browser and device"]
  end
  subgraph OktaZone["Okta"]
    F["Facts gathered: group, network, risk, proofs"]
    GSP["Global session policy and rules"]
    S["Session record and cookie"]
    APP["Application authentication policies"]
    LOG["System Log"]
  end
  A["Protected applications"]
  P --> B
  B -->|"Sign-in attempt"| F
  F --> GSP
  GSP -->|"Allow with limits"| S
  GSP -->|"Deny"| LOG
  S --> APP
  APP -->|"Access granted"| A
  S --> LOG

The components, one by one

Why the middle matters

Everything passes through the policy. That means a single place controls how Okta is entered, no matter which application the person wants in the end. A change to a session rule takes effect for every sign-in that matches it, which is both powerful and a reason to change it with care.

How Okta chooses a rule decides everything. Learn the evaluation order and half the confusion disappears.

A global session policy is assigned to one or more groups of people. Inside the policy is a list of rules, each with a priority number. When a person signs in, Okta first finds the policy that applies to them. Then it walks through that policy’s rules from the top, stopping at the first rule whose conditions all match. That rule’s actions are applied, and no later rule is considered.

flowchart TD
  S["Person signs in"] --> PO["Find the policy that applies to the person"]
  PO --> R1{"Rule 1 conditions match?"}
  R1 -->|"Yes"| A1["Apply Rule 1 actions"]
  R1 -->|"No"| R2{"Rule 2 conditions match?"}
  R2 -->|"Yes"| A2["Apply Rule 2 actions"]
  R2 -->|"No"| RN{"Further rules checked in order"}
  RN -->|"Match"| AN["Apply that rule"]
  RN -->|"No match"| CA["Catch-all rule applies"]

The order of rules matters

Because the first match wins, the order is part of the meaning. A broad rule placed above a specific one hides the specific rule completely. For example, a rule that says “everyone, any network, password only” placed at the top will catch every sign-in, and a later rule that asks for a second proof from unknown networks will never run.

Policy-level order too

When a person belongs to groups covered by more than one policy, the policies themselves have an order. Okta uses the policy with the highest priority that applies to the person. The person is then judged only by that policy’s rules, not by the rules of lower policies. This makes policy order as important as rule order.

Conditions are the facts a rule checks. The richer the facts, the finer the control.

A rule matches only when all of its conditions are true. Okta offers several kinds of conditions, and the exact list depends on your edition and version. Understanding each kind helps you write rules that are precise instead of blunt.

Common kinds of conditions

Writing conditions that behave

Narrow conditions make a rule easy to reason about. A rule that says “members of the Administrators group, from any network” is clear. A rule with six conditions joined together is harder to predict, and any one of them failing means the rule is skipped. Prefer several simple rules in a sensible order over one rule with a long, delicate list of conditions.

When a rule matches, its actions decide what happens next. Here is what a rule can do.

If conditions are the questions, actions are the answers. A rule’s actions fall into a few groups: whether access is allowed at all, which proof opens the session, whether a second proof is demanded, how often a person is asked again, and how long the session lasts. Together they define the experience for everyone the rule catches.

The main actions

Allow and deny

The simplest action is allow or deny. A deny rule stops the sign-in before any proof is checked. This is useful for networks or situations you never want to admit. An allow rule lets the sign-in continue, with the proof and session settings that follow. Deny rules usually sit high in the list, so that they are checked before any permissive rule can match.

Choosing the primary proof

For most people the primary proof is a password. In some setups, a person signs in through another identity provider, such as the company’s own login system, and Okta trusts that result. In more modern designs, any proof that satisfies the application’s authentication policy can be accepted. The right choice depends on your company’s identity design, so confirm the options available in your version.

The maximum lifetime is the hard ceiling on trust. Setting it well balances safety against comfort.

The maximum session lifetime is the longest time a session may live, counted from the moment it was created, no matter how active the person is. When the time is up, Okta ends the session and the person must sign in again. This protects against a session that quietly runs for days, long after the original sign-in was relevant.

Choosing a lifetime

There is no single right answer. A short lifetime is safer but means more frequent sign-ins. A long lifetime is more convenient but leaves a longer window for misuse. A common approach is to choose different lifetimes for different groups. Administrators and people who handle sensitive data get shorter lifetimes. Everyday staff on managed devices get longer ones.

Lifetime versus the apps behind it

Ending an Okta session does not always end every app session instantly. Many applications keep their own session once Okta has signed the person in. When the Okta session ends, the person will be asked to sign in again the next time Okta is needed, but an app that already holds its own session may continue until its own timer ends. Plan for this when you promise “everything signs out after eight hours”.

The quiet settings often matter more in practice than the loud ones.

The idle timeout ends a session after a period with no activity. It deals with the very common situation of someone who stops working but leaves a screen open, whether at a desk, a shared terminal, or a cafe table. The shorter the idle limit, the less time a walk-away leaves the account exposed.

Idle timeout in practice

Idle timeouts are especially important for shared devices and public spaces. A factory terminal that keeps a session open for hours between shifts is an open door. On the other side, a very short idle limit can annoy a developer who reads documentation for twenty minutes without clicking anything. Test the number with real users, not only on paper.

Persistent cookies

A cookie can either vanish when the browser closes, or stay stored on the computer for later. A persistent cookie lets the session survive closing and reopening the browser, which is convenient. A non-persistent cookie vanishes with the window, which is safer on shared computers.

A second proof is powerful, but asking too often tires people out. Frequency is a design choice.

A rule that requires a second proof must also say how often to ask for it. Okta lets you choose among a few styles. The right style depends on how trusted the device is and how sensitive the access is. The aim is to keep strong proof where it counts, without teaching people to click through prompts without thinking.

Common styles of prompting

Remember-device windows

When a device is remembered, Okta stores a note that this person passed the second proof there recently. The window of memory is a trade-off. A long window means fewer prompts, but a stolen device with a remembered note is more useful to a thief. A short window means more prompts but less exposure.

Prompt fatigue

If people see too many prompts, they stop reading them. Attackers know this and sometimes send repeated approval requests, hoping that a tired person will accept one. A calm design asks for strong proof clearly, rarely, and at moments that make sense, so that an unexpected prompt stands out.

Where a sign-in comes from tells you a lot. Network zones let policies use that clue.

A network zone is a named list of IP addresses or locations. Common examples are the office network, the VPN, a partner’s network, and a list of addresses known to be dangerous. Policies can refer to a zone by name, so rules stay readable, and so that changes in the address list update every rule that uses it.

Typical zone designs

Limits of location

Location is a helpful clue, but not proof. Attackers can hide behind anonymizing services, or use addresses in the same country as the victim. At the same time, honest people travel, work from cafes, and use mobile networks that change their addresses. A rule based only on location may block good people and miss bad ones. Combine it with other conditions and always keep a second proof as the main protection.

Some rules can react to how suspicious a sign-in looks, not only to fixed facts.

Beyond fixed conditions, Okta can look at patterns. Where such features are available in your edition, a rule can respond to a sign-in that is scored as risky, or to behavior that is unusual for that person, such as a new device, a new location, or a very unlikely travel jump between two places. These signals let policies adapt in the moment.

How adaptive rules help

Strengths and limits

Treat these signals as helpful additions, not as a replacement for good basics. Strong second proofs, sensible session limits, and clear admin rules still do most of the work. Adaptive rules sharpen the response at the edges.

Policies find people through groups. Good group design makes policies simple. Messy groups make them confusing.

Each global session policy is assigned to one or more groups. A person who belongs to a group covered by the policy falls under it. If the person belongs to several groups covered by different policies, the policy with the highest priority wins. This rule means that the order of policies, not only the order of rules, decides the outcome.

Designing groups for policy

A worked example

Notice how the strictest policy comes first. If an administrator also belongs to the contractor group by mistake, the administrator policy still wins, which is the safer outcome. Putting the most protective policies at the top is a simple habit that avoids many surprises.

Group hygiene

Policies are only as good as the groups behind them. If a person who should be an administrator is missing from the group, they escape the strict policy. If a contractor stays in the staff group after their contract ends, they keep a gentler policy than they should. Keep groups accurate through automation, based on trusted data from HR or the directory, and review them regularly.

Every account has a safety net. Understanding it is essential, because it quietly decides the outcome for anyone not covered elsewhere.

Okta provides a default global session policy that applies to everyone not covered by a higher-priority policy. Inside every policy, the last rule is a catch-all, which handles any sign-in that no earlier rule matched. The catch-all cannot be removed, because the system must always have an answer for every sign-in.

Why the catch-all matters

The catch-all rule is the answer to the question “what happens if none of my specific rules fit?” If the catch-all is generous, a person who slips through your specific rules gets easy access. If it is strict, the same person is stopped or challenged. Many real incidents come from a generous catch-all that nobody ever looked at.

A healthy overall shape

The people who can change security settings deserve the most careful session rules in the company.

An administrator account can create users, change policies, and reach sensitive data. If an attacker takes over such an account, the damage is far larger than for a normal account. For this reason, administrator sessions should be among the best protected, with strong proofs, short lifetimes, and close monitoring.

What strong administrator rules look like

Separate accounts for separate jobs

A safe habit is to give administrators two accounts: one for everyday work such as email, and one for administration. The everyday account follows the normal policy. The administration account follows the strict policy. If the everyday account is phished, the attacker still does not hold administrator rights.

Admin sessions have their own limits

Okta’s own administration console may apply additional limits, such as shorter time limits than ordinary sessions. These extra limits are designed to protect the most powerful area of the product. Read the current documentation to learn the exact values that apply to you, and do not assume that your global rules alone control them.

The session is what makes single sign-on work. It is also what an app may ask to refresh.

Single sign-on means a person signs in once and then opens many applications without typing credentials again. The Okta session is the thing that makes this possible. When the person opens an app, the app redirects to Okta, Okta sees the live session, and quietly confirms the person’s identity to the app.

What happens when the session is missing or old

Apps keep their own sessions too

Many applications create a private session of their own after Okta confirms who the person is. That private session has its own clock. If your Okta session ends but an app’s own session continues, the person may keep working in that app for a while. If you need an application to end quickly, you may need to set its own timeouts, or build in sign-out signals where the application supports them.

Freshness requirements

For sensitive apps, an authentication policy can require that the proof be recent. Even if the session is alive, a person who signed in six hours ago may be asked to prove themselves again before opening the payroll system. This keeps sensitive access close to the actual moment of proof.

Not everyone signs in with an Okta password. How the first proof is made shapes the session.

Some people sign in with a password stored in Okta. Others sign in with a password held in a company directory such as Active Directory. Others come through another identity provider, such as a partner’s login system or a social login. In each case, the global session policy still decides what happens, but the first proof comes from a different place.

Trusting an outside provider

When Okta trusts another identity provider, it is trusting that provider’s checks. If the provider only asks for a password, the proof is weak, even though Okta accepted it. A careful policy may require an additional proof at Okta for people arriving that way, or may restrict which groups may use that route at all.

Sessions in more than one place

When a person signs in through an outside provider, there may be two sessions: one at the provider and one at Okta. Ending one does not automatically end the other. This is a classic source of confusion when people say “I logged out but I was still signed in”. Understand where each session lives, and set timeouts at each place accordingly.

Follow one sign-in through every step, and see where each setting takes effect.

Putting the pieces together, a sign-in is a short conversation between the person, Okta, and sometimes an application. The policy takes part in the middle. The steps below show the typical order, though details vary with your configuration.

sequenceDiagram
  autonumber
  participant U as User
  participant B as Browser
  participant O as Okta
  participant P as Session policy
  participant A as Application
  U->>B: Open the application
  B->>A: Request access
  A->>O: Redirect to sign in
  O->>P: Evaluate rules for this person and situation
  P-->>O: Allow with required proofs and time limits
  O->>U: Ask for password and second proof
  U->>O: Provide proofs
  O->>B: Create session and cookie
  O->>A: Confirm identity
  A-->>U: Access granted

Step by step

Sometimes a session must end right now. Knowing how to do that is part of the policy story.

Most sessions end quietly, through the lifetime or idle limits. But some situations call for an immediate end: a lost laptop, a suspected stolen cookie, an employee who has just left, or an account that shows signs of an attack. In these cases, administrators can clear sessions so that the person must sign in again from scratch.

Ways a session can end

An incident response routine

The session policy is one of your most important security controls. Here is how it can fail, and how to keep it strong.

The global session policy sits at the door to every application behind Okta. A mistake in it can quietly open that door for many people at once. A well-designed policy, in contrast, makes theft of passwords much less useful, and shrinks the time any stolen session can be abused.

The main risks

Protective habits

The best policy on paper fails if people dislike living with it. Plan the human side as carefully as the technical one.

People accept security when it is quick, clear, and sensible. They resist it when it interrupts their work for no visible reason. A session policy changes how often people sign in and how often they see prompts, so every change is felt by real people at real desks.

What a good experience looks like

A sensible rollout plan

You cannot manage what you cannot see. A few steady signals show whether your policy is working.

Monitoring means watching a system’s health so that you hear about trouble before your users do. Logging means keeping a written diary of what happened. For session policy, the diary records sign-ins, denials, session starts, and session ends. Okta’s System Log is the main place to read it.

Where to look

Metrics worth tracking

Alerts that earn their keep

Set alerts for events that need a human: changes to session policies, many failed sign-ins for one account, sign-ins from blocked zones, and administrator sign-ins from unexpected places. Keep the list short, so that every alert still feels important.

Instead of memorizing errors, learn a method: find which rule applied, then ask why.

Almost every session policy problem is a version of “the wrong rule applied” or “the limits are not what I expected”. The method for both is similar. Identify the person, the situation, and the rule that matched. Then check whether the rule is the one you intended. Always ask what changed recently, since most surprises follow a change.

Walkthrough 1: A user is asked for a second proof too often

Walkthrough 2: Someone is not asked for the second proof at all

Walkthrough 3: A person is signed out unexpectedly

Walkthrough 4: A sign-in is denied

Read the System Log entry for the denial and note which rule applied. A deny rule that matches by network zone is the most common cause, often because the person is travelling or on a mobile network. Confirm whether the rule is working as intended. If it is, explain this to the person and offer a safe alternative, such as signing in through the company VPN.

No design is perfect. Here is an honest scorecard for session policy choices.

Key trade-offs in plain words

A pattern is a proven way of solving a repeating problem. An anti-pattern is a popular mistake.

Patterns that work

Anti-patterns to avoid

A short field guide of habits that save time and avoid late-night incidents.

Best practices, in order of when you meet them

Mistakes that appear again and again

When auditors visit, they ask how you control access to your systems. Your session policy is a central part of the answer.

Compliance means following rules set by law, customers, or the company itself. Many frameworks for security and privacy expect strong authentication, sensible session timeouts, and control of privileged access. Governance is the set of habits and records that let you show that these controls exist and work.

Evidence auditors often ask for

Governance habits that help

Privacy in plain words

Session policies use information about people, such as their location, device, and behavior. Collect only what the policy truly needs, tell people what is collected and why, and keep records only as long as required. Fewer stored details mean less to protect and less to explain if a regulator asks.

Here are four common situations where a well-built session policy earns its place. The companies are fictional teaching examples.

Public facts that give context

Security agencies and standards bodies around the world recommend multi-factor authentication and sensible session timeouts, because stolen credentials remain one of the most common causes of breaches. Okta, founded in 2009, built its business on connecting people to applications securely, and its policy engine is a central part of that work. The detailed setups of specific customers are not public, so the stories above remain fictional.

Quick answers to the questions that come up most often.

The whole guide in one place.

The global session policy is the rulebook for signing in to Okta. It reads the facts of each sign-in, finds the first matching rule, and decides whether access is allowed, which proofs are needed, and how long the resulting session may live. Used well, it protects the company without wearing people out.

A mental model to carry with you

When any session question lands on your desk, sort it into one of four buckets. The first bucket is selection: which policy and which rule applied to this sign-in? The second bucket is proof: what did the rule demand, and from which sources? The third bucket is time: how long may the session last and when does it go idle? The fourth bucket is reach: which applications and other sessions sit behind this one?

Most confusing situations turn out to be a mix-up between buckets. An unexpected prompt is usually a selection or proof problem. An unexpected sign-out is usually a time problem. A person who is still signed in to an app after logging out of Okta has a reach problem. Naming the bucket first tells you which logs to open and which setting to read.

This model also helps when you explain the design to others. Managers care about proof and time because they are about risk. Support teams care about selection because it explains complaints. Application owners care about reach because it covers their own sessions. A good identity architect speaks to all of them and keeps the plan written down.

A final word on the people behind the sign-in

Behind every sign-in is a real person trying to start their day, reach the tools they need, and get on with their work. Security that ignores this reality gets bypassed, resented, or quietly switched off. Security that respects it, by being quick, clear, and forgiving of honest mistakes, earns trust and keeps working for years.

For session policy, this means three promises. First, make the common path smooth, so that most people barely notice the extra checks. Second, make the risky path firm, so that unusual or dangerous situations meet real resistance. Third, make the whole design easy to explain, so that a new colleague can read it in an afternoon and understand why each choice was made.