Sessions
What a session is, what it records, how one is created and used, and the events that end it.
On this page
A session is identity's record that one browser is signed in to one account. It lives on identity's servers. The browser holds only an opaque reference to it, in a cookie. See Cookies.
A session is not a token. Applications never see it. They receive tokens that are tied to the session, and when the session ends, the tokens that depend on it stop refreshing. See Sessions and tokens.
What a session records#
| Record | What it is for |
|---|---|
| The account | Whose session it is. |
| The level and the methods | The assurance level reached and the methods used. They are carried into the tokens as acr and amr. |
| The organization | The organization the session is currently for, if one was chosen. See Organizations. |
| The connection | When you signed in through your organization's single sign-on connection, which connection it was. The session is then tied to it: it can enter only the organizations that connection is linked to (or that sit below one it is linked to). An application that asks for any other organization is treated as having no session, so you are asked to sign in. Connections and single sign-on enforcement are behind the flags tenant_connections and sso_enforcement, both OFF by default. |
| The device | The browser it was created on. See Trusted devices. |
| Times | When it started, when it was last active, when it will go idle and when it ends outright. See Session lifetimes. |
The account area lists most of this on the Sessions page: the device, the location, the IP address, Signed in, Last active, Idle timeout, Expires, the Sign-in method, the Assurance of the sign-in, the applications it is Signed in to, the Device status and, for a session that came through an organization's connection, the Company sign-in. See Sessions and devices.
How a session is created#
A sign-in is a short sequence of steps that identity tracks on its own side. The browser cannot skip a step. A sign-in in progress lasts 10 minutes. When every required step has been done, identity creates the session, and the sign-in in progress is deleted. If an application started the sign-in, the browser is then sent back to it.
Because the session is created once the steps are done, a new session always has a new identifier and a new secret. A cookie from an earlier session cannot carry over into it. Switching organization in the account area works the same way: it opens a new session rather than changing the old one, and the new session keeps the time the old one last authenticated.
How a session is used#
The session is looked up in the database on every request to identity. It is not trusted from the cookie alone. This has three consequences.
- It can be revoked at once. Ending a session, or closing or suspending the account, takes effect on the next request.
- It slides while you are active. The idle limit counts from your last activity, not from sign-in. Activity pushes the idle deadline out, but never past the absolute limit.
- One session signs you in everywhere. Every TDACorp application sends you to identity. If you already have a live session there, identity does not ask for your password again, so signing in to the next product is a redirect. That is single sign-on.
What ends a session#
| Event | Effect |
|---|---|
| The idle limit passes with no activity | That session ends. |
| The absolute limit passes | That session ends, however active it has been. |
| You select Sign out on a session | That session ends, and so do the refresh tokens that came from it. |
| You select Sign out everywhere | Every session ends, including the current one. |
| You change your password, remove a passkey or reset your authenticator app | Every other session and its refresh tokens end. The session you did it in carries on, with a new cookie secret, so a copy of the old cookie no longer works. Adding a passkey while securing your account in a recovery does the same. |
| You choose No, sign that session out on a sign-in alert | The alerted session ends, and so does every session the same browser opened since. |
| You choose No, secure my account | Every session and token ends, and the account is secured. See The unfamiliar browser check. |
| Your membership in an organization is suspended, removed or blocked | Your sessions for that organization end. Sessions for other organizations, and sessions with no organization, carry on. |
| Your account is closed or suspended | Every session ends. |
| An organization limits concurrent sessions | When you sign in past the limit, the oldest sessions in that organization end. "Oldest" is the order the sessions were opened in, not the time they last authenticated. |
| You switch organization in the account area | A new session is opened in the chosen organization and the one you left ends, unless an application you are signed in to still depends on it. |
A session that came in through the lost-passkey emailed code (see Authentication methods) cannot end any other session, or all sessions, on an account that holds a passkey or an authenticator app, until a second factor has been used in the last 30 minutes. It can still sign itself out.
When a session ends, applications that registered for back-channel logout are told, so they can end their own copy of it. See Back-channel logout.
An open account page checks regularly whether its own session still exists. A session you end from another browser therefore stops working in the first one as well.