Skip to main content
Authentication configuration controls how users authenticate with your Feathers application. It supports JWT tokens, local authentication (email/password), and OAuth providers.

Configuration Location

Authentication settings are stored in config/default.json and generated when you run the authentication generator:

Authentication Schema

The authentication configuration can be validated using schemas:

Core Settings

string
required
The secret key used to sign and verify JWT tokens. This should be a long, random string.Environment Variable: FEATHERS_SECRETSecurity: Never commit this to version control. Always use environment variables in production.Example: Generated automatically as a 32-character base64 string
string | null
The name of the entity (e.g., ‘user’) that is authenticated. Set to null for no entity.Default: The service name (e.g., user)
string
The name of the id property on the entity.Default: id (or _id for MongoDB)
string
The path of the service that provides the authentication entity.Example: users
string[]
required
List of authentication strategy names that are allowed to create JWT access tokens.Default: ['jwt', 'local']Common values: jwt, local, google, github, facebook, twitter, auth0
string[]
List of strategy names that should parse HTTP headers for authentication information.Default: Same as authStrategies

JWT Settings

object
Options passed to the JWT library for token generation and verification.
object
Configuration for JWT parsing from HTTP headers.

Local Authentication Settings

object
Configuration for email/password authentication.

OAuth Settings

object
Configuration for OAuth providers (Google, GitHub, Facebook, etc.).

Provider-Specific Settings

Each OAuth provider (google, github, facebook, twitter, auth0) has the same configuration structure:
object
Configuration for a specific OAuth provider.

Configuration Examples

Usage in Application

The authentication service is automatically configured:
src/authentication.ts

Testing Authentication

Test your authentication configuration:

Best Practices

Generate strong, random secrets for JWT signing. Use at least 32 characters and store them in environment variables.
Balance security and user experience. Short-lived tokens (1-7 days) are more secure but may require more frequent logins.
Never commit OAuth client IDs and secrets. Use environment variables and restrict access to production credentials.
Always use HTTPS for authentication endpoints in production to prevent token interception.
Set the audience field in JWT options to your application’s domain to prevent token misuse.
Use BCrypt with appropriate salt rounds (10-12). Never store plain-text passwords.