### disableAuth
\
Disable authentication & permissions checks.
NEVER set the to true in production. It exists
only to aid certain development tasks.
### tokenMethod
\
`} default={`'cookie'`} />
Sets the method by which the session token is delivered and read.
* 'cookie': Upon login, a 'Set-Cookie' header will be returned to the client, setting a
cookie containing the session token. A browser-based client (making requests with credentials)
should automatically send the session cookie with each request.
* 'bearer': Upon login, the token is returned in the response and should be then stored by the
client app. Each request should include the header `Authorization: Bearer `.
* 'api-key': The mutation `createApiKey` will return a generated API-Key once, which should then be
stored by the User. Each request should include the API-Key inside the header defined by `apiKeyHeaderKey`
('vendure-api-key' by default).
Note that if the bearer method is used, Vendure will automatically expose the configured
`authTokenHeaderKey` in the server's CORS configuration (adding `Access-Control-Expose-Headers: vendure-auth-token`
by default).
From v1.2.0 it is possible to specify both methods as a tuple: `['cookie', 'bearer']`.
From v3.6.0 it is possible to include 'api-key' as additional method in the method-tuple to allow for long-lived
API-Key based authorization.
### cookieOptions
\CookieOptions`} />
Options related to the handling of cookies when using the 'cookie' tokenMethod.
### authTokenHeaderKey
\
Sets the header property which will be used to send the auth token when using the 'bearer' method.
### apiKeyHeaderKey
\
Defines which header will be used to read the API-Key when using the 'api-key' token method.
### sessionDuration
\
Session duration, i.e. the time which must elapse from the last authenticated request
after which the user must re-authenticate.
If passed as a number should represent milliseconds and if passed as a string describes a time span per
[zeit/ms](https://github.com/zeit/ms.js). Eg: `60`, `'2 days'`, `'10h'`, `'7d'`
### sessionCacheStrategy
\SessionCacheStrategy`} default={`DefaultSessionCacheStrategy`} />
This strategy defines how sessions will be cached. By default, since v3.1.0, sessions are cached using
the underlying cache strategy defined in the [SystemOptions](/current/core/reference/typescript-api/configuration/system-options#systemoptions)`.cacheStrategy`.
### sessionCacheTTL
\
The "time to live" of a given item in the session cache. This determines the length of time that a cache entry
is kept before being considered "stale" and being replaced with fresh data taken from the database.
If passed as a number should represent seconds and if passed as a string describes a time span per
[zeit/ms](https://github.com/zeit/ms.js). Eg: `60`, `'2 days'`, `'10h'`, `'7d'`
### requireVerification
\
Determines whether new User accounts require verification of their email address.
If set to "true", the customer will be required to verify their email address using a verification token
they receive in their email. See the `registerCustomerAccount` mutation for more details on the verification behavior.
### verificationTokenDuration
\
Sets the length of time that a verification token is valid for, after which the verification token must be refreshed.
If passed as a number should represent milliseconds and if passed as a string describes a time span per
[zeit/ms](https://github.com/zeit/ms.js). Eg: `60`, `'2 days'`, `'10h'`, `'7d'`
### superadminCredentials
\SuperadminCredentials`} />
Configures the credentials to be used to create a superadmin
### shopAuthenticationStrategy
\AuthenticationStrategy[]`} default={`NativeAuthenticationStrategy`} />
Configures one or more AuthenticationStrategies which defines how authentication
is handled in the Shop API.
### adminAuthenticationStrategy
\AuthenticationStrategy[]`} default={`NativeAuthenticationStrategy`} />
Configures one or more AuthenticationStrategy which defines how authentication
is handled in the Admin API.
### customPermissions
\PermissionDefinition[]`} default={`[]`} />
Allows custom Permissions to be defined, which can be used to restrict access to custom
GraphQL resolvers defined in plugins.
### passwordHashingStrategy
\PasswordHashingStrategy`} default={`BcryptPasswordHashingStrategy`} since="1.3.0" />
Allows you to customize the way passwords are hashed when using the [NativeAuthenticationStrategy](/current/core/reference/typescript-api/auth/native-authentication-strategy#nativeauthenticationstrategy).
### adminApiKeyStrategy
\ApiKeyStrategy`} since="3.6.0" />
### shopApiKeyStrategy
\ApiKeyStrategy`} since="3.6.0" />
### passwordValidationStrategy
\PasswordValidationStrategy`} default={`DefaultPasswordValidationStrategy`} since="1.5.0" />
Allows you to set a custom policy for passwords when using the [NativeAuthenticationStrategy](/current/core/reference/typescript-api/auth/native-authentication-strategy#nativeauthenticationstrategy).
By default, it uses the [DefaultPasswordValidationStrategy](/current/core/reference/typescript-api/auth/default-password-validation-strategy#defaultpasswordvalidationstrategy), which will impose a minimum length
of four characters. To improve security for production, you are encouraged to specify a more strict
policy, which you can do like this:
*Example*
```ts
{
passwordValidationStrategy: new DefaultPasswordValidationStrategy({
// Minimum eight characters, at least one letter and one number
regexp: /^(?=.*[A-Za-z])(?=.*\d)[A-Za-z\d]{8,}$/,
}),
}
```
### verificationTokenStrategy
\VerificationTokenStrategy`} default={`DefaultVerificationTokenStrategy`} since="3.2.0" />
Allows you to customize the way verification tokens are generated.
### entityAccessControlStrategy
\EntityAccessControlStrategy`} default={`DefaultEntityAccessControlStrategy`} since="3.6.0" experimental="true" />
Allows you to define access control for entity queries at three levels:
* `canAccess()` — gate-level permission check (once per request)
* `prepareAccessControl()` — async pre-loading for row-level filtering (once per request)
* `applyAccessControl()` — synchronous row-level QB filtering (every entity query)
**Developer preview:** this API is subject to change in future releases.
### customerChannelAssignmentStrategy
\CustomerChannelAssignmentStrategy`} default={`DefaultCustomerChannelAssignmentStrategy`} since="3.7.0" />
Determines whether an authenticated Customer is auto-assigned to the active Channel.
This is skipped for the default channel, `disableAuth`, and registration/checkout flows.
The default strategy always assigns.