Authentication is required by almost every digital product, but implementing it correctly involves much more than a login form.
Registration, password security, email verification, account recovery, sessions, OAuth, and account linking all need to work together reliably.
Vuesion provides this foundation out of the box so authentication does not become the first large feature your team has to build.
Vuesion includes complete flows for:
These flows already include the corresponding pages, server endpoints, validation, database models, emails, and automated tests.
Vuesion separates a user from the methods used to authenticate that user.
A user represents the person inside the application.
An account represents an authentication method associated with that user, such as:
User
├── Credentials account
└── GitHub account
This distinction allows one user to authenticate through multiple providers without creating duplicate user profiles.
It also makes adding further OAuth providers possible without changing the central user model.
Regardless of how a user signs up, Vuesion always uses the same user creation flow.
Whether the account is created through credentials or GitHub OAuth, the application creates the complete foundation required by Vuesion:
Using a single creation flow guarantees that every user enters the application with the same consistent setup, regardless of the authentication method.
Authentication providers decide who the user is.
The shared user creation flow decides how a new user is initialized.
Credentials authentication uses an email address and password.
During registration, Vuesion:
The user remains in the setup state until the email address has been confirmed.
Passwords are never stored in plain text and are never returned to the client.
New credentials accounts must verify their email address.
Vuesion creates a temporary verification token and sends a confirmation link to the user. Once the link is opened successfully, the email address is marked as verified and the user account becomes active.
Verification tokens are:
Users can request another verification email if the original message expires or is lost.
The password recovery flow allows users to choose a new password without exposing whether unnecessary account information exists.
A temporary reset token is generated and sent to the account's email address.
After the token has been validated, the user can set a new password. The token is then invalidated so it cannot be reused.
Password recovery is implemented as a complete server-side flow rather than relying on client-side state.
Vuesion includes GitHub as its default OAuth provider.
When a user signs in with GitHub, Vuesion evaluates the returned account information in the following order:
Existing GitHub account?
│
├── Yes → Sign in the associated user
│
└── No
│
▼
Existing user with the same verified email?
│
├── Yes → Link the GitHub account
│
└── No → Create a new user and account
This prevents the same person from receiving duplicate users merely because they selected a different authentication method.
A newly created OAuth user is considered active because the identity and email information originate from the trusted provider. The same shared user creation flow also creates the initial settings, personal workspace, and workspace membership.
Authentication methods belong to accounts, while product data belongs to the user.
When GitHub returns an email address that already belongs to an existing user, Vuesion can associate the new GitHub account with that user instead of creating another one.
After linking, the user may sign in using either supported method while continuing to access the same:
Account linking is performed on the server and must only happen when the provider supplies sufficiently trustworthy account information.
Vuesion uses nuxt-auth-utils for session management.
Session data is stored in a secure, encrypted, and signed cookie. The cookie is sealed using the NUXT_SESSION_PASSWORD environment variable, preventing the browser from reading or modifying its contents.
Authenticated request
│
▼
Encrypted session cookie
│
▼
Nuxt server verifies and opens the session
│
▼
Current user information becomes available
Because the session is stored inside a cookie, only essential information should be included. Larger and frequently changing user data should be loaded from the database instead.
The useUserSession() composable exposes the current session state to the frontend and can refresh it through the session endpoint.
Vuesion typically keeps only the identity required to resolve the current user in the session. The complete user profile and permissions remain server-controlled.
The frontend uses the current session to improve the user experience.
It can:
These checks are not a security boundary.
Every protected server operation must independently verify the session and apply the required access control. A user must never gain access merely because the interface displayed an action.
Frontend check
└── Improves the experience
Server check
└── Enforces security
Additional OAuth providers can be added using the same account model and linking flow already used for GitHub.
A new provider generally requires:
The authentication architecture is intentionally provider-independent. Credentials and GitHub are included, but the underlying model is designed to support additional methods without introducing separate user systems.
Authentication affects many areas of a product and is difficult to retrofit once users and product data already exist.
Vuesion separates users, accounts, sessions, and product permissions from the beginning.
This provides:
The result is an authentication foundation that can grow with the product without becoming coupled to one provider.
Continue with Workspaces to learn how Vuesion organizes users, memberships, roles, and product data.