Sessions

User logs in with username and password [1]

1. Auth0's SDK redirects the user to the Auth0 Authorization Server (/authorize endpoint, from Auth0)
2. Your Auth0 Authorization Server creates a session (inside of the Auth0 environment), then redirects the user to the login and authorization prompt (still inside of the Auth0 application)
3. The user authenticates using their username and password and may see a consent page listing the permissions Auth0 will give to the application
4. Your Auth0 Authorization Server updates the previously-created session (this session still inside of the Auth0 environment only) to indicate that the user is logged in
5. Your Auth0 Authorization Server redirects the user back to our application, along with either an ID Token or code (depending on which flow that you use)
6. The application authenticates the user and creates a local session (now we have a session inside of our application)

As the result, two sessions are created:

• The local session (storezero.io): Allows the application to know if a user is authenticated.
• The session on the Authorization Server (storezero.auth0.com): Allows the Authorization Server to know if a user is authenticated and optionally, tracks other information.

<aside> 💡 The same proccess is done when user logs in with an identity provider, but we are going to have one step where the identity provider will create its own session and reply to Auth0 (still, our communication with Auth0 - and our session - will work the same way).

</aside>

References

[1] https://auth0.com/docs/manage-users/sessions

Cookies

<aside> 💡 Previously in Auth0, the samesite cookie attribute options were true, false, strict or lax. If you didn't set the attribute manually, Auth0 would use the default value of false. Effective February 2020, Google Chrome v80 changed the way it handles cookies. To that end, Auth0 implemented the following changes to how it handles cookies:

• Cookies without the samesite attribute set will be set to lax
• Cookies with sameSite=none must be secured, otherwise they cannot be saved in the browser's cookie jar

The goal of these changes are to improve security and help mitigate CSRF attacks.

</aside>

The sameSite attribute [4]

Cookie-based authentication is implemented by each web platform differently, but at the end of the day, they all end up setting some cookie (tied to a session on the server) which represents the authenticated user. On each request, that cookie is sent and the session is deserialized from some store (in memory if it's a single server or some persistent storage if it's a server farm). We provide SDKs for most of the platforms that will tie into the corresponding authentication subsystem (such as passport on node, IPrincipal on .NET or Java, and so on).

When you build an application that requires authentication, you can use sessions and cookies to determine if a user is authenticated each time a request is made. To do this, you can choose to use either stateful or stateless cookies.