Demo Authentication Server
API
It's POST /api/v3/core/users/ — the same endpoint the test suite just used to create svc-oat-test. For a regular human user it's a two-step process, because creation and password-setting are separate calls:
1. Create the user:
AKTOK=<authentik API token> # e.g. the bootstrap token from /opt/authentik/.env
curl -s -X POST https://auth.2.88.io/api/v3/core/users/ \ -H "Authorization: Bearer $AKTOK" \ -H "Content-Type: application/json" \ -d '{ "username": "alice", "name": "Alice Example", "email": "alice@example.com", "type": "internal", "is_active": true }'
The response includes the new user's pk. Field notes: username and name are required; type is internal for normal users, service_account for machine identities (what we used for API voters), external for federated-only users; groups takes a list of group pks if you want membership at creation time.
2. Set the password (separate endpoint, using the pk from step 1):
curl -s -X POST https://auth.2.88.io/api/v3/core/users/<pk>/set_password/ \ -H "Authorization: Bearer $AKTOK" \ -H "Content-Type: application/json" \ -d '{"password": "<their-initial-password>"}'
Useful related endpoints, all under the same base: GET /api/v3/core/users/?username=alice to look up, PATCH /api/v3/core/users/{pk}/ to modify (that's how akadmin got added to misp-admin — groups are patched as a full list of pks), and for service accounts, POST /api/v3/core/tokens/ + GET /api/v3/core/tokens/{identifier}/view_key/ to mint the app password used in the client-credentials flow.
Once created, that user can immediately sign in to Own AI Trust via the header's Sign in link and their votes will record under their username — nothing to configure on the Trust side. One suggestion if you start adding real users: create them via authentik's UI instead (Directory → Users) unless you're automating — the UI handles password-reset-on-first-login flows that the raw API leaves to you.