Let's see how to maintain application sessions in different scenarios.
Terminology
- SSO — Single sign-on
- SLO — Single Logout
- redirect_uri — The callback URL after login
- returnTo — The callback URL after logout
- TLD — Top level domain
- ITP — Intelligent tracking prevention (by Apple)
- IdP — Identity provider
Problem Definition
An application can determine the validity of an Auth0 Session via the use of /authorize endpoint. Customers often implement some kind of polling against Auth0 /authorize to determine the session validity and this may not be viable given the potential impact of hitting rate limits, ITP, and third-party cookie issues. This document describes scenarios on how to avoid such issues and implement approaches to maintain app sessions.
Implementation Details
Sessions
A session identifies the user to the app after they have logged in, and is valid for a period of time during which the user can perform a set of interactions within that application. A single session can contain multiple activities (such as page views, events, social interactions, and e-commerce transactions), all of which are stored in the session temporarily while the user is connected.
Session layers:
There are basically three layers of sessions:
- Application session Though the application uses Auth0 to authenticate users, it may still need to track that the user has logged in to the application. For which, it may have to create a session (for eg., by depending on an access_token expiration).
- **Auth0 session **Auth0 also keeps a session for the user and stores their information inside a cookie. The next time a user is redirected to the Auth0 login, the user's information will be inferred.
- IdP session: This session is involved when Auth0 is federating to another third-party IdP.
In addition to the above session layers, the application also has to be aware of token expirations, especially in OIDC flows.
- Session vs Token: When a user successfully logs in, a session is created and maintained by Auth0 and indicates that the user has logged in and does not need to re-authenticate for the duration of that session. The session will last until a set expiration time or the user logs out, or the SSO session cookie is deleted from the user’s browser. So if a user leaves an application but later returns and attempts to login before the session expires they will not have to enter their credentials again. On the other hand, tokens are signed information that Auth0 sends back to the client application in a way to securely exchange the user authentication and authorization decisions with the client applications. Access tokens represent authorization and are intended to grant the bearer access to an API either on behalf of a user or an application. Id tokens represent authentication and contain information about the user who authenticated and are intended for the application the user is using.
SSO, SLO & how they work:
Single Sign-on (SSO) occurs when a user logs in to one application and is then signed in to other applications in that agent/browser automatically. The user signs in only one time, hence the name of the feature (Single Sign-on).
Whenever users go to a domain that requires authentication, they are redirected to the centralized authentication domain where they may be asked to log in. If the user is already logged in at the authentication domain, the central authentication server will automatically re-authorize and re-consent(if required) the user’s request to the application and then the user can be immediately redirected to the original domain without signing in again.
Logout in the context of Auth0 implementation is the act of terminating an authenticated session. Auth0 provides tools to help you give users the ability to log out; this includes options for providing different levels of logout and also determining where the user will land after the logout is complete.
- Application Session Layer Logout: Logging users out of your applications typically results in their application session being cleared, and this should be handled by your application: for the Application Session Layer, there is nothing within your Auth0 tenant that you need to use to facilitate session termination.
- **Auth0 Session Layer Logout: **You can log users out of the Auth0 session layer by redirecting them to the Auth0 Logout endpoint so Auth0 can clear the SSO cookie.
- Identity Provider Session Layer Logout: It is not necessary to log the users out of this session layer, but you may be able to use Auth0 to force the logout, if required, by passing a parameter to the Auth0 Logout endpoint (if supported by third party IDP). This is applicable for SAML scenarios and other scenarios are covered in the next sections.
Maintain Sessions in SPAs and Regular Web Apps
App session with a backend:
Applications with a backend may track sessions with a server-side application session (a server-side cookie). This cookie may track its expiration by depending on the token response from Auth0. If the cookie expires, the backend has a few options to get the token response from Auth0 and then slide the app session.
- Perform a 302(redirect) to Auth0 /authorize endpoint. Here, if the session is still valid on Auth0, then new tokens are replied back on the callback service without asking for the user to re-login.
- During initial authentication, request for a refresh token. Later, the backend can use refresh token to get the new tokens when the app session expires. This approach makes your backend a stateful service and can be extended to be a centralized session management service. The session cookie may only store an anchor (an identifier stored in it) and every time the front end makes a call to the backend, the cookie is associated with the request. The backend will get the refresh token(if required) from the storage using the mapped identifier (or anchor) in the app session cookie. However, this solution will be useful only when the front end & backend are tied to the same TLD.
- Review our Regular web app Quickstarts & SDKs for the implementation details.
Top comments (0)