Sessions

A session is a group of interactions between a user and an application during a given timeframe. A single session may consist of multiple activities (such as page views, events, social interactions, and e-commerce transactions) and can store this information temporarily while the user is connected.

With a standard Set-Cookie header implementation, a session ends when a user leaves a website or closes their browser. To prevent users from having to log in every time, applications can extend sessions by setting a maximum lifetime for the session cookie. Sessions end when a user logs out or a session lifetime limit is reached.

To learn more, review Auth0 Privacy and Cookie Policy.

Auth0 maintains a login session for any user who authenticates through an application. When a user performs a new standard login, Auth0 resets the login session. Updating a password, email, or phone number also causes a user's Auth0 session to expire.

When you build an application requiring authentication, you can use sessions to determine whether a user is authenticated each time a request occurs. Depending on how your app has been built, different authorization flows are recommended to support a more secure experience for users.

For example, consider an OIDC-compliant (OpenID Connect) website called storezero.io.

Storezero.io does not require its users to log in to complete purchases. However, users must log in to view the My Account section of the site. 

For the use cases listed below, consider a scenario where a user wants to review their previous orders prior to checking out. To do so, they navigate to the All Orders page of the My Account section and are prompted to log in. 

Most types of applications (such as web apps, single-page apps, and native apps) should use the Authorization Code Flow with PKCE to facilitate login authentication. This flow involves exchanging an authorization code for tokens.

In this example, a user manually logs in using their username and password:

1. Auth0's SDK creates a local session and redirects the user to the Auth0 authorization server (/authorize endpoint).

2. The authorization server creates a session, then redirects the user to the login and authorization prompt.

3. The user authenticates using their username and password.

4. The Auth0 authorization server updates the user’s previously-created session to indicate they are logged in.

5. Depending on the flow used, the authorization server returns the user to your application, along with either an ID token or an authorization code.

6. Your application exchanges the token or authorization code for an access token and completes the flow.

With this flow, two sessions are created:

• The local session (storezero.io), which indicates to the application whether a user is authenticated.

• The authorization server session (storezero.auth0.com), which indicates to the server whether a user is authenticated. The server session can also optionally track details about the authentication.

  • For example, the authorization server can track if a user leveraged multi-factor authentication (MFA). This information can then be used to determine whether a user should be prompted to log in or use MFA the next time they arrive at the authorization server.

In this example, the user opts to log in with Facebook instead of their username and password: 

1. Auth0's SDK creates a local session and redirects the user to the Auth0 authorization server (/authorize endpoint).

2. The authorization server creates a session, then redirects the user to the login and authorization prompt. 

3. Upon choosing to log in with Facebook, the authorization server redirects the user to Facebook. 

4. Facebook creates a session and authenticates the user. Facebook then updates its session to indicate the user is logged in. 

5. Facebook returns the user to the Auth0 authorization server. The authorization server then updates its session to indicate the user is logged in.

6. Depending on the flow used, the authorization server returns the user to your application, along with either an ID token or an authorization code.

7. Your application exchanges the token or authorization code for an access token and completes the flow.

In this scenario, three sessions are created: the local session (storezero.io), the authorization server session (storezero.auth0.com), and an identity provider (IdP) session (facebook.com).

The IdP session on Facebook's server authenticates the user and provides a seamless SSO experience. As there is a high probability that users are already logged in to Facebook, users are often authenticated without having to manually provide their Facebook credentials.

In the previous examples, a local session is created when the user initiates either login flow. This local session can keep users logged in and determine when they need to reauthenticate.

However, local sessions are not available for applications without backends, such as single-page apps (SPAs). Instead, these applications use a different approach known as silent authentication to keep users logged in.

Silent authentication uses the session on the authorization server to determine when a user must reauthenticate. A hidden iframe redirects authentication requests to the authorization server along with the prompt=none parameter. This parameter prevents the server from prompting the user for input.

• If the session on the authorization server has not expired, the transaction continues seamlessly. The server sends an access token through WMRM (Web Message Response Mode), which leverages postMessage. 

• If the session on the authorization has expired or the user logs out, the redirect in the iframe returns an error. The application must then direct the user to the authorization server for reauthentication.

• Session Layers
• Session Lifetime Limits
• Configure Session Lifetime Settings
• Cookies
• SameSite Cookie Attribute Changes
• Authenticate Single-Page Apps With Cookies