---
title: Session Management
description: Understand access and refresh tokens, automatic session refresh, protected API verification, cookies, and session revocation.
sidebar:
  order: 10
---

## Session lifecycle summary

- Signing in creates a session and issues access and refresh tokens to the frontend.
- Protected API calls verify the access token and its expiry.
- When an access token expires, the frontend uses the refresh token to obtain new tokens and retries the original request.
- Revoking a session removes its refresh token and session information, so refresh fails and the user must log in again.

## Overview

SuperTokens provides session management out of the box.
Sessions get created when a user signs in and maintained throughout the authentication lifecycle.
In the next graphic you can see a high level overview of how the session flow works.

<Frame>
  <img
    class="docs-image-content-width"
    alt="Flowcharts showing an overview of session flow"
    src="/docs-assets/img/session_flow.png"
  />
</Frame>

- After sign in, the system creates a new session by issuing a refresh and access token to the frontend.
- The frontend sends the access token for each API call that requires session authentication.
- These API calls verify the access token and its expiry. If verification fails, the API throws a session expired error, else, execution continues.
- If an API throws session expired error, the frontend uses its refresh token to get a new refresh and a new access token. The frontend performs this action via a special API on your backend. If you revoke a session, this API also throws session expired after which the user has to login again.
- After obtaining a new set of tokens, the frontend retries the original API call, yielding the desired result.
- To revoke a session, the backend removes the refresh token and its session information from its database.

## Information about session cookies

| Cookie Name | Description |
|-------------|-------------|
| `sAccessToken` | This is the session's access token which each API call uses to verify that the user authenticated and to get their user ID (when using cookie based authentication). |
| `sRefreshToken` | This is the session's refresh token which retrieves a new access (and refresh token) when the existing access token expires (when using cookie based authentication). |
| `sFrontToken` | Used to access a session's access token payload and user ID on the frontend without exposing the `sAccessToken`. |
| `sAntiCsrf` | Used to prevent CSRF attacks. |
| `st-last-access-token-update` | Used by the frontend to know if a session exists, and when the access token has changed. |
| `st-access-token` | Used by the frontend to store the access token for header based authentication. |
| `st-refresh-token` | Used by the frontend to store the refresh token for header based authentication. |

## Getting started

Including the `Session` recipe in the initial configuration enables sessions.
This step is outlined in all the guides that show you how to integrate different authentication methods: [Email Password](/authentication/email-password/introduction), [Passwordless](/authentication/passwordless/introduction) or [Social Login](/authentication/social/introduction).

Additionally, this section includes information on how to work with sessions after a user has signed in.

<CardGroup cols={3}>
  <Card title="Access Session Data" href="/post-authentication/session-management/access-session-data">
See how you can read the properties of an active session.
</Card>
  <Card title="Invalidate Sessions" href="/post-authentication/session-management/session-invalidation">
Learn how to revoke a session either through a user action or programmatically.
</Card>
</CardGroup>

## Customization 

<CardGroup cols={3}>
  <Card title="Share sessions across subdomains" href="/post-authentication/session-management/share-session-across-sub-domains">
Update the configuration to share sessions across different subdomains.
</Card>
  <Card title="Switch between cookie and header based authentication" href="/post-authentication/session-management/switch-between-cookies-and-header-authentication">
Choose how tokens are sent and stored during the authentication lifecycle.
</Card>
  <Card title="Implement anonymous sessions" href="/post-authentication/session-management/advanced-workflows/anonymous-session">
Learn how to track session data event if a user has not logged in.
</Card>
  <Card title="Implement user impersonation" href="/post-authentication/session-management/advanced-workflows/user-impersonation">
See how to act as a different user during the authentication flow.
</Card>
  <Card title="Customize error handling" href="/post-authentication/session-management/advanced-workflows/customize-error-handling">
Change the default error handling behaviour.
</Card>
  <Card title="Work with multiple API endpoints" href="/post-authentication/session-management/advanced-workflows/multiple-api-endpoints">
Use the same session management logic for multiple API endpoints.
</Card>
  <Card title="Blacklist Access Tokens" href="/post-authentication/session-management/advanced-workflows/access-token-blacklisting">
Block access tokens from being used.
</Card>
</CardGroup>