[data-reveal]{opacity:1!important;transform:none!important}
Introduction
Interfaces

Introduction

The auth domain answers who is calling: authentication decorators, tokens and sessions, users and external identities.

Overview

The auth domain of @antelopejs/interface-dms answers one question for the DMS: who is calling. It resolves the bearer token on an HTTP request into a User row, issues and validates the tokens that make such a request possible, records logins as sessions, binds the accounts a user owns on external login providers, and owns the users, sessions and user_external_identities tables together with their models.

It stops at identity. Deciding what an authenticated caller is allowed to do — permissions, roles, tenant membership — belongs to the Core domain, whose tenant guards build on the authenticateRequestUser function documented here.

The domain is published under three subpaths:

SubpathContents
@antelopejs/interface-dms/authThe authentication decorators, authenticateRequestUser, the token generators and validators, createSession, sanitizeUser, the external-identity functions, announceRegistration, and the account mail entry points.
@antelopejs/interface-dms/auth/dbThe User, Session and UserExternalIdentity tables, their models, and the table-name constants.
@antelopejs/interface-dms/auth/passwordThe password policy: PASSWORD_MIN_LENGTH, PASSWORD_PATTERN and isPasswordCompliant. Pure values, usable without the DMS loaded.

Key Features

  • Request Authentication Decorators — Gate a route, a controller property, or a whole controller class on a valid bearer token with AuthUser and AuthRawUser, and receive the resolved User.
  • Optional Authentication — Serve the same route to signed-in and anonymous callers with IfAuthUser, which injects User | undefined instead of rejecting the request.
  • Owner-Only Gate — Restrict administration surfaces to platform owners with AuthOwnerOnly, which answers 403 to an authenticated non-owner.
  • Composable Authentication — Build your own parameter providers on authenticateRequestUser, the same primitive the DMS tenant guards start from.
  • Token Lifecycle — Issue and validate tenant-scoped access and refresh tokens, plus the short-lived two-factor and tenant-assignment tokens that stand between a password check and a real session.
  • Revocable Sessions — Record each login as a Session row carrying its device, IP and current refresh token, so a single session or every session of a user can be revoked.
  • User Table and Model — A User table with hashed passwords through HashModifier, and a UserModel with lookups by email and by owner flag.
  • External Login Providers — Bind the accounts a user owns on GitHub, Google or any configured provider with linkExternalIdentity, and resolve a provider profile back to a user on the next login.
  • Safe Responses — Strip authentication secrets from a user with sanitizeUser before returning it over HTTP.
  • One Password Policy — Check a password against the policy the DMS enforces with isPasswordCompliant, so a module's own signup accepts exactly what the DMS accepts.
  • Account Emails — Send the second-factor, email-validation, password-reset and invite messages the authentication flows depend on.
  • One Registration Path — Run the notifications and the USER_REGISTERED hook through announceRegistration, whichever flow created the account.

Dependencies

This interface relies on the following AntelopeJS packages:

Quick Start

The following controller gates a route on an authenticated user and returns the account with its secrets stripped.

import { Controller, Get } from "@antelopejs/interface-api";
import {
  AuthUser,
  sanitizeUser,
} from "@antelopejs/interface-dms/auth";
import type { User } from "@antelopejs/interface-dms/auth/db";

export class ProfileController extends Controller("/api/profile") {
  @Get("")
  profile(@AuthUser() user: User): Promise<Partial<User>> {
    // 401 before this line runs when the token is missing or invalid
    return sanitizeUser(user);
  }
}

A client reaches it by sending the access token issued at login in the Authorization header, as Bearer <access token>.

Documentation Sections

  • Authentication - Resolve a request to a user with the authentication decorators and authenticateRequestUser
  • Tokens and Sessions - Issue and validate access, refresh, two-factor and tenant-assignment tokens, and record login sessions
  • Users - The user table and model, password hashing, the password policy, sanitization, the account mail entry points, and announcing a registration
  • External Identities - Bind and read the accounts a user owns on external login providers