* docs: changes based on DX changes * remove fields no longer needed * remove unnecessary parameters * fixes to authenticate middleware usage * add highlight to migrations config * change configuration to http * added missing remote link docs * fix name in sidebar * added notification module docs + updated file module docs * add vale exceptions * fix vale errors * added docs on custom cli scripts
59 lines
1.8 KiB
Plaintext
59 lines
1.8 KiB
Plaintext
---
|
||
sidebar_label: "Persisting Auth User"
|
||
---
|
||
|
||
export const metadata = {
|
||
title: `Persisting Auth User Authentication`,
|
||
}
|
||
|
||
# {metadata.title}
|
||
|
||
In this document, you’ll learn what the `AuthUser` is and how to persist its authentication.
|
||
|
||
## What is an AuthUser?
|
||
|
||
As explained in the [Auth Provider](../auth-providers/page.mdx) guide, when a user or customer is authenticated, you receive an `authUser` object:
|
||
|
||
```ts
|
||
const { success, authUser } =
|
||
await authModuleService.authenticate("emailpass", {
|
||
// ...
|
||
})
|
||
```
|
||
|
||
The `authUser` object is a record of the `AuthUser` data model. It has details about the authenticated user or customer, such as their ID, email, and other details.
|
||
|
||
<Note>
|
||
|
||
Learn more about the `AuthUser`'s fields in [this reference](/references/auth/models/AuthUser).
|
||
|
||
</Note>
|
||
|
||
---
|
||
|
||
## Persisting Authentication
|
||
|
||
While the Auth Module provides the authentication functionality, it doesn’t provide the functionality to persist the authentication, as that depends on your application’s requirements.
|
||
|
||
For example, the Medusa application’s authentication route signs the `authUser` object into a JSON Web Token (JWT):
|
||
|
||
```ts
|
||
const {
|
||
success,
|
||
authUser,
|
||
} = await service.authenticate(auth_provider, authData)
|
||
|
||
// ...
|
||
const {
|
||
jwtSecret,
|
||
} = req.scope.resolve("configModule").projectConfig.http
|
||
|
||
const token = jwt.sign(authUser, jwtSecret)
|
||
```
|
||
|
||
Then, the token is passed in the header of subsequent requests in the Authorization Bearer header.
|
||
|
||
An authentication middleware verifies the token and attaches the associated `authUser`'s details to the `auth` property of the request object passed to the subsequent middlewares and route.
|
||
|
||
If the authentication middleware can’t verify the token, the user isn’t authenticated and they’re asked to login again.
|