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
-[Run custom code before Auth Handlers](#run-custom-code-before-auth-handlers)
52
-
-[Run code after callback](#run-code-after-callback)
52
+
-[Run custom code before Auth Handlers](#run-custom-code-before-auth-handlers)
53
+
-[Run code after callback](#run-code-after-callback)
53
54
54
55
## Passing authorization parameters
55
56
@@ -164,7 +165,7 @@ On the server, the `getSession()` helper can be used in Server Components, Serve
164
165
165
166
> [!NOTE]
166
167
> The `getSession()` method returns a complete session object containing the user profile and all available tokens (access token, ID token, and refresh token when present). Use this method for applications that only need user identity information without calling external APIs, as it provides access to the user's profile data from the ID token without requiring additional API calls. This approach is suitable for session-only authentication patterns.
167
-
For API access, use `getAccessToken()` to get an access token, this handles automatic token refresh.
168
+
> For API access, use `getAccessToken()` to get an access token, this handles automatic token refresh.
168
169
169
170
```tsx
170
171
import { auth0 } from"@/lib/auth0";
@@ -779,6 +780,7 @@ This will in turn, update the `access_token`, `id_token` and `expires_at` fields
779
780
For applications where an API call might be made very close to the token's expiration time, network latency can cause the token to expire before the API receives it. To prevent this race condition, you can implement a strategy to refresh the token proactively when it's within a certain buffer period of its expiration.
780
781
781
782
The general approach is as follows:
783
+
782
784
1. Before making a sensitive API call, get the session and check the `expiresAt` timestamp from the `tokenSet`.
783
785
2. Determine if the token is within your desired buffer period (e.g., 30-90 seconds) of expiring.
784
786
3. If it is, force a token refresh by calling `auth0.getAccessToken({ refresh: true })`.
@@ -987,6 +989,7 @@ export const auth0 = new Auth0Client({
987
989
## Transaction Cookie Configuration
988
990
989
991
### Customizing Transaction Cookie Expiration
992
+
990
993
You can configure transaction cookies expiration by providing a `maxAge` proeprty for `transactionCookie`.
991
994
992
995
```ts
@@ -997,11 +1000,13 @@ export const auth0 = new Auth0Client({
997
1000
},
998
1001
}
999
1002
```
1003
+
1000
1004
Transaction cookies are used to maintain state during authentication flows. The SDK provides several configuration options to manage transaction cookie behavior and prevent cookie accumulation issues.
| cookieOptions.maxAge | `number`| The expiration time for transaction cookies in seconds. Defaults to `3600` (1 hour). After this time, abandoned transaction cookies will expire automatically. |
1036
-
| cookieOptions.prefix | `string`| The prefix for transaction cookie names. Defaults to `__txn_`. In parallel mode, cookies are named `__txn_{state}`. In single mode, just `__txn_`. |
1037
-
| cookieOptions.sameSite | `"strict" \|"lax" \|"none"`| Controls when the cookie is sent with cross-site requests. Defaults to `"lax"`. |
1038
-
| cookieOptions.secure | `boolean`| When `true`, the cookie will only be sent over HTTPS connections. Automatically determined based on your application's base URL protocol if not specified. |
1039
-
| cookieOptions.path | `string`| Specifies the URL path for which the cookie is valid. Defaults to `"/"`. |
| cookieOptions.maxAge | `number` | The expiration time for transaction cookies in seconds. Defaults to `3600` (1 hour). After this time, abandoned transaction cookies will expire automatically. |
1044
+
| cookieOptions.prefix | `string` | The prefix for transaction cookie names. Defaults to `__txn_`. In parallel mode, cookies are named `__txn_{state}`. In single mode, just `__txn_`. |
1045
+
| cookieOptions.sameSite | `"strict" \|"lax" \|"none"` | Controls when the cookie is sent with cross-site requests. Defaults to `"lax"`. |
1046
+
| cookieOptions.secure | `boolean` | When `true`, the cookie will only be sent over HTTPS connections. Automatically determined based on your application's base URL protocol if not specified. |
1047
+
| cookieOptions.path | `string` | Specifies the URL path for which the cookie is valid. Defaults to `"/"`. |
1040
1048
1041
1049
## Database sessions
1042
1050
@@ -1063,6 +1071,28 @@ export const auth0 = new Auth0Client({
1063
1071
});
1064
1072
```
1065
1073
1074
+
## Using Client-Initiated Backchannel Authentication
1075
+
1076
+
Using Client-Initiated Backchannel Authentication can be done by calling `getTokenByBackchannelAuth()`:
- `bindingMessage`: A human-readable message to be displayed at the consumption device and authentication device. This allows the user to ensure the transaction initiated by the consumption device is the same that triggers the action on the authentication device.
1090
+
- `loginHint.sub`: The `sub` claim of the user that is trying to login using Client-Initiated Backchannel Authentication, and to which a push notification to authorize the login will be sent.
1091
+
1092
+
> [!IMPORTANT]
1093
+
> Using Client-Initiated Backchannel Authentication requires the feature to be enabled in the Auth0 dashboard.
1094
+
> Read [the Auth0 docs](https://auth0.com/docs/get-started/authentication-and-authorization-flow/client-initiated-backchannel-authentication-flow) to learn more about Client-Initiated Backchannel Authentication.
1095
+
1066
1096
## Back-Channel Logout
1067
1097
1068
1098
The SDK can be configured to listen to [Back-Channel Logout](https://auth0.com/docs/authenticate/login/logout/back-channel-logout) events. By default, a route will be mounted `/auth/backchannel-logout` which will verify the logout token and call the `deleteByLogoutToken` method of your session store implementation to allow you to remove the session.
@@ -1424,6 +1454,7 @@ export async function middleware(request: NextRequest) {
1424
1454
Authentication routes (`/auth/login`, `/auth/logout`, `/auth/callback`) are handled automatically by the middleware. You can intercept these routes in your middleware to run custom logic before the auth handlers execute.
1425
1455
1426
1456
This approach allows you to:
1457
+
1427
1458
- Run custom code before authentication actions (logging, analytics, validation)
1428
1459
- Modify the response (set cookies, headers, etc.)
1429
1460
- Implement custom redirects or early returns when needed
@@ -1435,49 +1466,48 @@ The middleware-based approach provides the same level of control as v3's custom
1435
1466
### Run custom code before Auth Handlers
1436
1467
1437
1468
Following example shows how to run custom logic before the response of `logout` handler is returned:
1469
+
1438
1470
```ts
1439
1471
exportasyncfunction middleware(request) {
1472
+
// prepare NextResponse object from auth0 middleware
1473
+
const authRes =awaitauth0.middleware(request);
1440
1474
1441
-
// prepare NextResponse object from auth0 middleware
"The authorization server does not support backchannel authentication. Learn how to enable it here: https://auth0.com/docs/get-started/applications/configure-client-initiated-backchannel-authentication"
0 commit comments