The following documentation provides a detailed explanation of Corbado session management. If you already have a session management in place that you want to keep or want to use another session management solution, please check the “Own session management” section.

After successful user authentication, Corbado creates a session. A session represents a logical connection between a user and the application, spanning multiple requests and responses.

Corbado employs a combination of technologies for its session management, ensuring a highly secure and user-friendly solution.

​
Session

Upon creating a session, Corbado records an entry in its session database. This entry is used for managing the status and lifetime of the session.

Additionally, it allows us to display all sessions in the developer panel and revoke them when needed.

​
session-token

Besides creating a session entry in the database, Corbado also generates a session-token.

The session-token is implemented through the usage of JSON Web Tokens (JWT). It is passed within your application and serves as a means to verify user authentication (refer to the Protecting routes section for more details).

If session refresh is enabled, the session-token has a limited lifespan, ensuring enhanced security.

The session-token is stored as a cookie by the Corbado UI component (with the name cbo_session_token, refer to Cookie Security for more details).

​
refresh-token

To enhance the security of the refresh mechanism (if enabled), a second token is generated: the refresh-token.

Everytime a session-token is refreshed (generating a new one) the refresh-token is needed.

The refresh-token is stored as a cookie by the Frontend API (with the name cbo_refresh_token, refer to Cookie Security for more details).

Previously, the refresh-token was referred to as a long-term session, which is now deprecated. However, it is still stored in a cookie named cbo_long_session for backward compatibility.

​
Advantages

Implementing session management like this offers the following advantages:

  • Database-stored sessions can be listed and inspected in the developer panel, providing a comprehensive overview of users currently logged in and the devices they are using
  • Database-stored sessions can be revoked using the developer panel
  • The session-token implemented as JWT can be verified client-side in less than 1ms through standard JWT verification
  • The session-token has the ability to carry additional user information through claims
  • The refresh-token enhances security by requiring a second token for session refresh

​
Security

Please refer to our security section for a comprehensive understanding of the security advantages offered by our session design.

​
Comparison to OAuth2

If you’re interested in understanding how Corbado compares to OAuth2, please refer to our OAuth2 comparison section.

Next, it is essential to protect your routes (both frontend and backend) by checking if a user is authenticated and take appropriate actions accordingly.

The following documentation provides a detailed explanation of Corbado session management. If you already have a session management in place that you want to keep or want to use another session management solution, please check the “Own session management” section.

After successful user authentication, Corbado creates a session. A session represents a logical connection between a user and the application, spanning multiple requests and responses.

Corbado employs a combination of technologies for its session management, ensuring a highly secure and user-friendly solution.

​
Session

Upon creating a session, Corbado records an entry in its session database. This entry is used for managing the status and lifetime of the session.

Additionally, it allows us to display all sessions in the developer panel and revoke them when needed.

​
session-token

Besides creating a session entry in the database, Corbado also generates a session-token.

The session-token is implemented through the usage of JSON Web Tokens (JWT). It is passed within your application and serves as a means to verify user authentication (refer to the Protecting routes section for more details).

If session refresh is enabled, the session-token has a limited lifespan, ensuring enhanced security.

The session-token is stored as a cookie by the Corbado UI component (with the name cbo_session_token, refer to Cookie Security for more details).

​
refresh-token

To enhance the security of the refresh mechanism (if enabled), a second token is generated: the refresh-token.

Everytime a session-token is refreshed (generating a new one) the refresh-token is needed.

The refresh-token is stored as a cookie by the Frontend API (with the name cbo_refresh_token, refer to Cookie Security for more details).

Previously, the refresh-token was referred to as a long-term session, which is now deprecated. However, it is still stored in a cookie named cbo_long_session for backward compatibility.

​
Advantages

Implementing session management like this offers the following advantages:

  • Database-stored sessions can be listed and inspected in the developer panel, providing a comprehensive overview of users currently logged in and the devices they are using
  • Database-stored sessions can be revoked using the developer panel
  • The session-token implemented as JWT can be verified client-side in less than 1ms through standard JWT verification
  • The session-token has the ability to carry additional user information through claims
  • The refresh-token enhances security by requiring a second token for session refresh

​
Security

Please refer to our security section for a comprehensive understanding of the security advantages offered by our session design.

​
Comparison to OAuth2

If you’re interested in understanding how Corbado compares to OAuth2, please refer to our OAuth2 comparison section.

Next, it is essential to protect your routes (both frontend and backend) by checking if a user is authenticated and take appropriate actions accordingly.