Authentication

The current TattooAPI runtime supports two auth paths:

JWT bearer tokens for user-scoped flows like login, refresh, profile, and API key management
API keys for server-to-server usage where a user context is already established

Current Reality

POST /auth/register creates a user and returns a success message plus user identity.
POST /auth/login returns top-level user and tokens.
POST /auth/refresh returns fresh top-level tokens.
GET /auth/profile and PUT /auth/profile require auth.
GET /api-keys and POST /api-keys require auth and use the standard success wrapper.

Create an account with email, password, name, and optional role metadata.

Exchange email and password for access_token and refresh_token.

Attach Bearer Token

Send Authorization: Bearer <token> to protected endpoints.

Refresh

Use POST /auth/refresh before the access token expires.

Use a logged-in user to create an API key, then attach it as:

X-API-Key: YOUR_API_KEY

The API key management endpoints are part of the supported public surface. They are a platform control layer, not a domain object.

The current auth runtime still reflects the legacy role system:

These roles are runtime access constructs. The ontology remains the domain source of truth.

Treat the ontology package as canonical for future tool and SDK generation.
Treat the current auth flows as the runtime baseline until the contracts are unified.
Never assume a legacy verified boolean means the same thing as ontology-level verificationStatus.