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
Sometimes it is useful to obtain the access token directly, for instance to make API requests to another service.
233
+
Access tokens are available through the `getAccessToken()` function within your loader. This design encourages server-side token usage while making the security implications explicit.
**Note:** Only expose access tokens to the client when necessary for your use case (e.g., making direct API calls from the browser). Consider alternatives like:
284
+
- Making API calls server-side in your loaders
285
+
- Creating proxy endpoints in your application
286
+
- Using separate client-specific tokens with limited scope
287
+
288
+
#### Using with `ensureSignedIn`
289
+
290
+
When using the `ensureSignedIn` option, you can be confident that `getAccessToken()` will always return a valid token:
// With ensureSignedIn: true, the user is guaranteed to be authenticated
296
+
const accessToken =getAccessToken();
297
+
298
+
// Use the token for your API calls
299
+
const data =awaitfetchProtectedData(accessToken);
300
+
301
+
return { data };
302
+
}, { ensureSignedIn: true });
303
+
```
304
+
305
+
### Using withAuth for low-level access
306
+
307
+
For advanced use cases, the `withAuth` function provides direct access to authentication data, including the access token. Unlike `authkitLoader`, this function:
308
+
309
+
- Does not handle automatic token refresh
310
+
- Does not manage cookies or session updates
311
+
- Returns the access token directly as a property
312
+
- Requires manual redirect handling for unauthenticated users
0 commit comments