accounts-express

Source code of released version | Source code of development version

---

Express middleware and authenticated fetch helpers for Meteor accounts. Lets you authenticate plain HTTP requests (REST endpoints, custom Express routes, server-to-server calls) using the same login tokens that DDP already issues — no separate auth layer required.

What you get

• createAuthMiddleware([options]) — Express middleware that resolves a Meteor login token from the Authorization: Bearer header or the meteor_login_token cookie, looks up the user, and exposes req.userId. Inside next(), Meteor.userId() / Meteor.userAsync() work via the current endpoint invocation context.
• A wrapped Meteor.fetch (and fetch from meteor/fetch) that understands auth: true and, on the server, token: '...'. When auth is on, the login token is attached as a Bearer header.
• fetch exported from meteor/accounts-express — same as above but auth-on-by-default. Pass auth: false to opt out.

Installation

meteor add accounts-express

This package implies accounts-base and depends on webapp on the server.

Server: protecting an Express route

1import express from "express";
2import { WebApp } from "meteor/webapp";
3import { createAuthMiddleware } from "meteor/accounts-express";
4
5const app = express();
6
7// required: true → 401 when no/invalid/expired token
8// required: false (default) → req.userId is null and the request continues
9app.use("/api", createAuthMiddleware({ required: true }));
10
11app.get("/api/me", async (req, res) => {
12  const user = await Meteor.userAsync();
13  res.json({ userId: req.userId, email: user?.emails?.[0]?.address });
14});
15
16WebApp.handlers.use(app);

Token resolution order:

1. Authorization: Bearer <token> header
2. meteor_login_token cookie

Tokens are validated against Meteor.users.services.resume.loginTokens and checked against Accounts._getTokenLifetimeMs(). Expired or unknown tokens behave according to the required flag.

Authenticated fetch

Loading this package wraps Meteor.fetch so it understands two extra options:

Option	Where	Default	Effect
auth	client + server	false	When true, attaches the login token as Authorization: Bearer …
token	server only	—	Explicit token; implies auth: true unless auth: false is set

1// Opt-in auth via Meteor.fetch
2const res = await Meteor.fetch("/api/me", { auth: true });
3
4// Or via the meteor/fetch package
5import { fetch } from "meteor/fetch";
6await fetch("/api/me", { auth: true });
7
8// Auth-on-by-default ergonomic
9import { fetch } from "meteor/accounts-express";
10await fetch("/api/me");           // auth: true
11await fetch("/public", { auth: false });

Server-side specifics

• Inside an authenticated request handled by createAuthMiddleware, calling auth: true (without token) reuses the current request's login token via the endpoint invocation context. This implicit forwarding is restricted to same-origin URLs, so a handler that fetches a third-party host will not leak the user's token to it.
• Pass token: '...' to use an explicit token regardless of context.

Client-side specifics

• token is server-only and is stripped on the client.
• When Accounts._useHttpOnlyCookies is enabled, auth: true also sets credentials: 'include' so the browser sends the meteor_login_token cookie automatically.

TypeScript

Type definitions are shipped with the package and augment meteor/meteor and meteor/fetch so auth / token show up on Meteor.fetch and fetch options.

See also

• accounts-base — the underlying account system
• webapp — Meteor's Express-compatible HTTP server
• fetch — Meteor's universal fetch package