Auth Flow

The platform uses two separate authentication mechanisms depending on who is making the request.

Admin and Publisher Auth (JWT)

Editors and publishers authenticate with a username and password. The backend issues a JWT token that the dashboard stores and sends with every request.

Admin/Publisher Login Flow

1. User POSTs credentials to /api/v1/auth/login.
2. Backend validates credentials and signs a JWT containing the user ID and role.
3. Dashboard stores the JWT (localStorage or context) and attaches it to all future requests.
4. Each protected request includes: Authorization: Bearer <token>
5. protect middleware verifies the token and attaches req.user to the request.
6. admin or publisher middleware then checks the role before allowing the action.

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Middleware Types

Middleware	What it checks
protect	Token is valid and user exists — all logged-in users pass
admin	User role is admin — full access
publisher	User role is publisher — limited to own feed/articles

Child-Site Auth (API Key)

Child-site frontends don’t have user accounts. They authenticate using a shared API key.

Child-Site API Key Flow

1. Child-site frontend calls an endpoint under /api/v1/client/*.
2. Request includes the API key as a header or query param.
3. authenticateApiKey middleware compares it to the API_KEY env var.
4. Backend returns the content or responds with 403.

x-api-key: your-api-key-here

Or as a query param:

GET /api/v1/client/posts?api_key=your-api-key-here

Note

The API key is a single shared secret — all child sites use the same one. It is set in news-server/.env as API_KEY.