Cookies
How identity uses cookies to hold a session and short sign-in steps, what protects them, and how they relate to the cookies of the applications you sign in to.
On this page
Identity uses cookies for one job: to connect a browser to something that lives on identity's servers. The cookie never holds your data. It holds a reference.
The authoritative list of every cookie, with its lifetime and attributes, is on the Cookies and local storage page. This page explains the idea behind them and does not repeat that list.
The session cookie#
When you sign in, identity creates a session and gives the browser a cookie named __Host-tdaid_sid. Its value is a random secret. Identity stores only a one-way digest of that secret, so a copy of the database cannot be turned back into working cookies. The cookie says nothing about who you are. On each request identity looks the secret up and finds the session.
That has practical effects.
- Signing out works. Ending a session on the server makes the cookie useless, even in a browser that still holds it.
- The cookie lasts as long as the session can. Its lifetime is the session's absolute limit. The server ends the session sooner if it goes idle or is revoked. See Session lifetimes.
- Changing a credential changes the cookie. After you change your password or remove a passkey, the session you did it in carries on with a fresh secret, and other sessions end. A stolen copy of the old cookie stops working.
The organization hint cookie#
The cookie __Host-tdaid_org remembers which organization you last entered on this browser, so the account area can name it again and offer it the next time. It holds the organization's identifier and nothing else, and identity sets it only after an organization switch has passed every check. It is only a hint. Identity's server never reads it as proof of anything; the account pages check it against your active memberships each time and ignore it if you can no longer enter that organization. Its lifetime is a runtime setting, one year by default and between 1 and 400 days. The account Sign out button clears it; signing out some other way leaves it until it expires. See Changing organization.
What protects a cookie#
Every cookie on the identity host except the language preference is set by the server and carries the same protections.
| Protection | What it does |
|---|---|
HttpOnly | A script on the page cannot read it. |
Secure | The browser sends it only over HTTPS. |
SameSite=Lax | The browser does not send it on cross-site requests that change something. |
The __Host- prefix | The browser itself refuses the cookie unless it is Secure, has path / and has no Domain. A sibling subdomain cannot set or overwrite it, and it is sent only to the identity host. |
Identity also checks that every request which changes something comes from its own pages. SameSite=Lax is one layer of that protection and the check is the other. There is no separate request-forgery cookie.
Cookies for a sign-in in progress#
A sign-in, a sign-up and a recovery are each several steps. Short-lived cookies keep a step tied to the browser that began it.
- A sign-in in progress is held by a cookie that carries only the sign-in's identifier, for 10 minutes. An emailed sign-in link or code works only in the browser that holds it.
- Sign-up uses two short cookies that bind the emailed code and the verified link to the browser that registered.
- Recovery uses a cookie so that a recovery link opens only in the browser that asked for it. This is why a recovery link opened on another device asks you to start again.
- The optional passkey offer sets a cookie so that, if you skip it, you are not asked again for 7 days.
The device cookie#
The device cookie is the longest lived of them, up to 400 days, and it outlives the session. It carries a random value that lets your account recognise a browser it has seen before. It is not personal data. It is what the trusted devices list and the unfamiliar browser check rely on. Removing a device from your account stops the account recognising its cookie, and clearing cookies in your browser makes the next sign-in look new.
What identity does not do#
- It sets no analytics, advertising or tracking cookies, and loads nothing from third parties.
- It does not use
localStorage,sessionStorageor IndexedDB. - It shows no cookie banner. Every cookie it sets is one that signing in needs, except a small language preference that your own browser writes only when you pick a language with the switcher on a sign-in page. It holds just the language code. See Languages.
- It has no cookie-free mode. If your browser blocks these cookies, you cannot sign in.
Applications set their own cookies#
Single sign-on does not mean the applications share identity's cookie. The identity cookie is sent only to the identity host. Each application you sign in to sets its own cookies on its own domain, and manages its own session. The application learns who you are from tokens it receives, not from the identity cookie. Those cookies are not listed on identity's pages, and an application should describe its own.
When you sign out of an application, its own session may end without ending your identity session. When you sign out of identity, applications that registered for back-channel logout are told. See Sessions.