# Extract user and application routes into a dedicated auth domain

* Status: accepted
* Date: 2026-05-01

## Context and Problem Statement

User authentication/registration routes (`/api/cms/user`) were grouped under the CMS domain, and API key application routes (`/api/skydive/applications`) were grouped under the Skydive domain. Neither resource is domain-specific content: users and applications are identity and access management concerns shared across all domains.

## Decision Drivers

* The domain prefix should reflect what a resource *is*, not which feature first needed it.
* `/api/cms/user` implies users are CMS content; `/api/skydive/applications` implies API keys are skydive data — both are misleading.
* A dedicated `auth` domain makes the security boundary explicit and easier to apply targeted middleware (rate limiting, stricter CORS, etc.) in the future.

## Considered Options

* Keep routes in their current domains
* Move only users out of CMS, leave applications in skydive
* Create a dedicated `auth` domain for both

## Decision Outcome

Chosen option: "dedicated `auth` domain", because both resources are identity/access concerns and grouping them together makes the API surface self-documenting.

Changes made:
- `src/routes/api/auth/` created with `users.routes.js`, `applications.routes.js`, and `index.js`
- `/user` removed from `src/routes/api/cms/index.js`
- `/applications` removed from `src/routes/api/skydive/index.js`
- `/auth` domain registered in `src/routes/api/index.js`
- Frontend `user.service.ts` and `applications.service.ts` updated: `_apiDomain` changed from `/cms` and `/skydive` to `/auth`

Resulting routes: `/api/auth/user/*` and `/api/auth/applications/*`.

### Positive Consequences

* API domain structure matches resource semantics — auth concerns are isolated from content and feature domains.
* A single place to tighten auth-specific middleware (rate limiting, IP allowlists, audit logging) without touching other domains.

### Negative Consequences

* Breaking change on the API surface — any client other than the Angular frontend calling the old paths must be updated.

## Pros and Cons of the Options

### Keep routes in current domains

* Good, because no migration effort.
* Bad, because the domain prefix actively misleads — users are not CMS content, applications are not skydive data.

### Move only users out of CMS

* Good, because smaller change.
* Bad, because applications in skydive remains wrong, and two related resources end up in different places.

### Dedicated auth domain

* Good, because both resources land where their semantics say they belong.
* Good, because the auth boundary is explicit and ready for future hardening.
* Bad, because it is a breaking change requiring a coordinated update of all consumers.