A session is a group of interactions between a user and an application that take place within a given timeframe. A single session can contain multiple activities (such as page views, events, social interactions, and e-commerce transactions), all of which the session stores temporarily while the user is connected.

By default, when a user leaves a website or closes their browser, their session ends. To keep users from having to log in every time they return, applications can extend sessions by storing session information in a cookie. Sessions end when a user logs out or when session lifetime limits are reached. Resetting a user's password, email, or phone number causes their PeakCommerce session to expire.

PeakCommerce’s IAM, 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.

When you build an application that requires authentication, you can use sessions to determine if a user is authenticated each time a request is made. For instance, suppose you have an OIDC-compliant e-commerce website called storezero.io.

The sections below walk through user activity on storezero.io with a focus on session management.

When checking out, a storezero.io user isn't required to log in to the site. However, to view the "My Account" pages, the user must log in.

Suppose that, before checking out, a user wants to view their previous orders. They navigate to the "All Orders" section in the "My Account" pages.

1. Auth0's SDK redirects the user to the Auth0 authorization server (/authorize endpoint).

2. The Auth0 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 previously-created session to indicate that the user is logged in.

5. The Auth0 authorization server redirects the user back to the application, along with either an ID Token or code (depending on which flow that you use).

6. The application authenticates the user.

Two sessions are created in the steps above:

• The local session (storezero.io) lets the application know if a user is authenticated.

• The session on the authorization server (storezero.auth0.com) lets the authorization server know if a user is authenticated and, optionally, tracks other information. For example, the authorization server can track whether a user has authenticated using MFA. If so, the next time the user arrives at the authorization server, they won't need to see a login page or be prompted to use MFA again.

Let's say that instead of using their username and password, the user decides to log in with Facebook.

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

2. The Auth0 authorization server creates a session.

3. The Auth0 authorization server redirects the user to the login prompt.

4. The user chooses to log in with Facebook.

5. The Auth0 authorization server redirects the user to Facebook's server.

6. Facebook creates a session, then authenticates the user, and updates the session to indicate that the user is logged in.

7. Facebook redirects the user back to the authorization server, where the Authorization Server updates its session to indicate that the user is logged in.

8. The authorization server redirects the user back to the application, along with either an ID token or code (depending on which flow you use).

9. The application authenticates the user and updates its local session to indicate that the user is logged in.

In addition to the two sessions created in the previous example, a third session is created in the identity provider scenario:

• The session on Facebook's server (facebook.com): Allows Facebook to know if the user is authenticated and if so, provides an SSO experience for the user. Since there’s a high probability that the user is already logged in to Facebook, if they choose to log in to storezero.io using Facebook, they will likely not be prompted to enter their credentials.

When you build an application that requires authentication, you can use sessions to determine if a user is authenticated each time a request is made. This example is accurate for SPAs that have no backend and are using the Implicit Flow.

Let's say that the user decides to log in with Facebook.

1. Auth0's SDK redirects the user to the Auth0 authorization server (/authorize endpoint).

2. The Auth0 authorization server creates a session.

3. The Auth0 authorization server redirects the user to the login prompt.

4. The user chooses to log in with Facebook.

5. The Auth0 authorization server redirects the user to Facebook's server.

6. Facebook creates a session, then authenticates the user, and updates the session to indicate that the user is logged in.

7. Facebook redirects the user back to the authorization server, where the authorization server updates its session to indicate that the user is logged in.

8. The authorization server redirects the user back to the application, passing an ID Token and Access Token.

9. The application authenticates the user.

Because we are using the Implicit Flow, the client (storezero.io) can consume the ID token to authenticate the user and can use the access token to interact with the API (until it expires). So no local session is created to keep the user logged in.

Because we have no local session to keep the user logged in, we can use the session on the Authorization Server to determine whether to force the user to reauthenticate. We do this through Silent Authentication.

We create a hidden iframe that redirects to the authorization server adding the prompt=noneparameter, which tells the server not to prompt the user for any input. If the session on the authorization server has not expired, the transaction continues seamlessly, and the client gets a new access token through WMRM (Web Message Response Mode), which leverages postMessage.

If the session on the authorization server has expired or the user logs out, the redirect in the iframe will return an error, indicating that the application needs to redirect the user to the authorization server to reauthenticate.