You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/sessions/references/sample-use-cases-sessions.md
+43-10
Original file line number
Diff line number
Diff line change
@@ -7,15 +7,13 @@ contentType: concept
7
7
useCase:
8
8
- build-an-app
9
9
---
10
-
# Use Cases: Sessions
10
+
# Session Use Cases
11
11
12
-
Auth0 maintains a login session for any user who authenticates via an application. When a user performs a new standard login, it resets the login session.
12
+
## For SPAs using Authorization Code grant
13
13
14
-
When you build an application that requires authentication, you can use [sessions](/sessions) to determine if a user is authenticated each time a request is made. Let's look at an example.
14
+
Auth0 maintains a login session for any user who authenticates via an application. When a user performs a new standard login, it resets the login session.
15
15
16
-
::: note
17
-
This example is accurate for native apps, regular web apps, and single-page apps (SPAs) with a lightweight backend that are using the Authorization Code grant. For SPAs with no backend, see [Sample Use Cases: Sessions and Single-Page Apps](/sessions/references/sample-use-cases-sessions-spas).
18
-
:::
16
+
When you build an application that requires authentication, you can use [sessions](/sessions) to determine if a user is authenticated each time a request is made. These examples are for SPAs that have a lightweight backend and are using the Authorization Code grant (also, native apps and regular web apps.
19
17
20
18
Let's say you've built an OIDC-compliant e-commerce website called Storezero.io.
21
19
@@ -25,7 +23,7 @@ When checking out, a user can optionally log in to the site, but to view the "My
25
23
26
24
Before checking out, a user wants to view their previous orders, so they navigate to the "All Orders" section in the "My Account" pages.
27
25
28
-
## User logs in with Username and Password
26
+
###User logs in with username and password
29
27
30
28
1. Auth0's SDK redirects the user to the Auth0 Authorization Server (**/authorize** endpoint).
31
29
2. Your Auth0 Authorization Server creates a session, then redirects the user to the login and authorization prompt.
@@ -40,7 +38,7 @@ Two sessions are created:
40
38
41
39
* 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. For example, the Authorization Server can track whether a user has authenticated using [Multi-factor Authentication (MFA)](/multifactor-authentication). 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.
42
40
43
-
## User logs in with Identity Provider
41
+
###User logs in with identity provider
44
42
45
43
Let's say that instead of using their username and password, the user decides to log in with Facebook.
46
44
@@ -54,16 +52,51 @@ Let's say that instead of using their username and password, the user decides to
54
52
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).
55
53
9. The application authenticates the user and updates it's local session to indicate that the user is logged in.
56
54
57
-
In addition to the two session created in the previous example, a third session is created:
55
+
In addition to the two sessions created in the previous example, a third session is created:
58
56
59
57
* The session on Facebook's server (facebook.com): Allows Facebook to know if the user is authenticated and if so, provides a <dfndata-key="single-sign-on">[Single Sign-on (SSO)](/sso)</dfn> 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.
60
58
59
+
## For SPAs with no backend using the Implicit grant
60
+
61
+
When you build an application that requires authentication, you can use [sessions](/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 grant.
62
+
63
+
Let's say you've built an OIDC-compliant e-commerce website called Storezero.io.
64
+
65
+
66
+
67
+
When checking out, a user can optionally log in to the site, but to view the "My Account" pages, the user _must_ log in.
68
+
69
+
Before checking out, a user wants to view their previous orders, so they navigate to the "All Orders" section in the "My Account" pages.
70
+
71
+
### User logs in with identity provider
72
+
73
+
Let's say that the user decides to log in with Facebook.
74
+
75
+
1. Auth0's SDK redirects the user to the Auth0 Authorization Server (**/authorize** endpoint).
76
+
2. Your Auth0 Authorization Server creates a session.
77
+
3. Your Auth0 Authorization Server redirects the user to the login prompt.
78
+
4. The user chooses to log in with Facebook.
79
+
5. Your Auth0 Authorization Server redirects the user to Facebook's server.
80
+
6. Facebook creates a session, then authenticates the user, and updates the session to indicate that the user is logged in.
81
+
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.
82
+
8. The Authorization Server redirects the user back to the application, passing an ID Token and Access Token.
83
+
9. The application authenticates the user.
84
+
85
+
Since we are using the Implicit Grant, 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.
86
+
87
+
### Keep the user logged in without a local session
88
+
89
+
Since 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](/api-auth/tutorials/silent-authentication).
90
+
91
+
We create a hidden iframe that redirects to the Authorization Server adding the `prompt=none` parameter, 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.
92
+
93
+
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.
0 commit comments