canonical: https://jentic.com/apis/phantauth.net/phantauth

# PhantAuth

PhantAuth generates deterministic mock user profiles, OAuth clients, and test tokens from arbitrary input strings without any database storage. It provides 10 endpoints covering user generation, client registration mocking, token issuance, team and fleet management, tenant configuration, and domain setup. The same username or client_id always produces identical data, making it ideal for repeatable authentication testing in CI pipelines and development environments.

## For AI agents

Generate deterministic mock users, OAuth clients, tokens, teams, and tenants for authentication testing. The same input always returns the same identity data without any database.

## Scope

Does not handle real user authentication, production identity management, or secure token signing - use for mock identity generation and testing only.

## Capabilities

- Generate reproducible mock user profiles from arbitrary username strings
- Issue test ID tokens and access tokens for OAuth flow validation
- Create mock OAuth client registrations for client credential testing
- Organize mock users into named teams for multi-user scenarios
- Group mock clients into fleets for multi-application testing
- Configure mock tenants and domains for multi-tenant auth testing

## Use cases

### Repeatable OAuth Integration Testing

Test OAuth 2.0 authorization code and client credential flows against deterministic mock identities. GET `/user/{username}` produces a stable user profile, GET `/client/{client_id}` returns a consistent client registration, and token endpoints issue valid-format test tokens. Every test run sees identical identity data, eliminating flakiness from random test fixtures.

Example prompt: Get mock user via GET `/user/qa-user-001`, retrieve client via GET `/client/test-app`, then get an ID token via GET `/user/qa-user-001/token/id` to validate the full OAuth flow

### CI Pipeline Authentication Fixtures

Provide consistent authentication test data for CI/CD pipelines without database seeding or external dependencies. PhantAuth endpoints are stateless and deterministic, so pipeline steps can fetch the same user profiles and tokens across parallel runs. Teams (GET `/team/{teamname}`) provide groups of related test identities for scenarios requiring multiple users.

Example prompt: Fetch a team of 5 mock users via GET `/team/qa-team`, generate access tokens for each via GET `/user/{username}/token/access`, and validate all tokens have consistent claims

### Multi-Tenant Application Testing

Simulate multi-tenant identity scenarios using GET `/tenant/{tenantname}` for tenant configurations and GET `/domain/{domainname}` for domain-level settings. Agents can test tenant isolation, cross-tenant access prevention, and tenant-scoped user lookups without provisioning real infrastructure. Each tenant name deterministically produces a unique configuration.

Example prompt: Create tenant config via GET `/tenant/acme`, create a second via GET `/tenant/globex`, then verify user profiles generated under each tenant have different tenant-scoped attributes

### AI Agent Mock Identity via Jentic

AI agents discover PhantAuth through Jentic when they need test identities for validating authentication integrations. Agents search by intent, receive typed schemas, and generate deterministic users and tokens immediately. No credential setup is required since PhantAuth is publicly accessible.

Example prompt: Search Jentic for 'generate a test OAuth token', load the GET `/user/{username}/token/{kind}` schema, and execute with username 'agent-test' and kind 'access'

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| GET | `/user/{username}` | Get a deterministic mock user profile |
| POST | `/user` | Create a user selfie with custom data |
| GET | `/user/{username}/token/{kind}` | Generate a user token |
| GET | `/client/{client_id}` | Get a mock OAuth client |
| GET | `/client/{client_id}/token/{kind}` | Generate a client token |
| GET | `/team/{teamname}` | Get a group of mock users |
| GET | `/fleet/{fleetname}` | Get a group of mock clients |

## Key resources

- **Users** — Generate and retrieve deterministic user profiles with selfie creation
- **Clients** — Generate and retrieve mock OAuth client registrations
- **Tokens** — Issue ID tokens and access tokens for users and clients
- **Teams** — Retrieve named groups of related mock users
- **Fleets** — Retrieve named groups of related mock clients
- **Tenants** — Configure mock tenant environments
- **Domains** — Retrieve domain-level configurations

## Why Jentic

- **Setup:** Wiring PhantAuth by hand means formatting requests against phantauth.net for its user, client, team, and fleet paths and interpreting the generated identity responses yourself; the API needs no auth. Through Jentic you install once, import PhantAuth from the API Directory, and your agent calls it.
- **Permission scoping:** PhantAuth puts the resource id in the URL path (`/user/{username}`, `/client/{client_id}`, `/team/{teamname}`), so a rule can pin your agent to one user, client, or team; the create-user target travels in the request body, so there you limit the agent to the operations it needs. You choose the operations it may call, so creating a user is not included unless you add it.
- **Credential handling:** PhantAuth needs no credential, so there is none for Jentic to store; if you configure an optional token, it is stored once, encrypted, by your own Jentic One instance and injected at execution time, never entering the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'generate a fake test user', and Jentic returns the matching PhantAuth operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **PhantAuth (main slug)** — Same PhantAuth API available under the main catalog slug.
- **Auth0 API** — Auth0 is the production identity platform that PhantAuth helps test integrations for.
- **FusionAuth API** — FusionAuth provides a self-hosted identity platform that PhantAuth can mock during development.

## FAQ

### Does PhantAuth require any authentication to use?

No. All PhantAuth endpoints are publicly accessible without credentials. The service generates mock identity data only and is not a secured production system. Agents can call any endpoint immediately.

### How does the deterministic user generation work?

PhantAuth uses the username string as a seed to generate all profile attributes (name, email, phone, avatar URL) through a deterministic algorithm. No data is stored. The same username always produces exactly the same profile, enabling repeatable tests without database fixtures.

### Can I generate OAuth tokens for testing?

Yes. GET `/user/{username}/token/{kind}` generates user tokens where kind is 'id' or 'access'. GET `/client/{client_id}/token/{kind}` generates client tokens. Tokens are formatted like real OAuth tokens for integration testing but are not cryptographically secured for production use.

### How do I test multi-tenant scenarios through Jentic?

Search Jentic for 'get mock tenant configuration' to find GET `/tenant/{tenantname}.` Execute with different tenant names to get deterministic configurations. Combine with GET `/user/{username}` using tenant-scoped usernames to test tenant isolation logic in your application.

### What is the difference between user selfie and regular user retrieval?

GET `/user/{username}` generates a user from the username deterministically. POST /user (create user selfie) allows you to provide custom profile data that overrides the generated defaults, useful when you need specific test attributes while keeping other fields auto-generated.

### Can I limit what my agent is allowed to do with the PhantAuth API?

Yes. Because you run Jentic One yourself, your own rules decide which PhantAuth operations and any optional token the agent may use. PhantAuth puts the resource id in the URL path for GET `/user/{username}`, GET `/client/{client_id}`, and GET `/team/{teamname}`, so a rule can pin the agent to a single user, client, or team, while the create-user target travels in the POST /user body where you restrict it to the operations it needs. Because you choose the operations the agent may call, creating a user or issuing a token stays unavailable unless you add it.