# Overview

Pick the right WAMP credential for the job — signing a human in, acting for a user from your backend, or acting as your app itself.

Source: https://docs.vampikez.fun/identity/overview/

Choose credentials by the API receiving them. OIDC sign-in, platform
management, app installations, end-user model access, and connected resources
have distinct issuers or audiences; they are not interchangeable.

## What you need before any code

Configure these values for the deployment before issuing or verifying tokens.

| Value | What it is | How to get it |
|---|---|---|
| `$API` | The Account API origin. Every `/auth/*` and `/api/*` call on these pages is relative to it | On this deployment it is `https://api.vampikez.fun`; on another, ask for its Account origin |
| `$ISSUER` | The OIDC issuer. It always ends in `/oauth2` | On this deployment it is `https://account.vampikez.fun/oauth2`; every OIDC endpoint is then discovered from `$ISSUER/.well-known/openid-configuration` |
| `$TOKEN_ISSUER` | The issuer of platform-signed non-OIDC tokens and the required `aud` of an app assertion | `https://api.vampikez.fun` on this deployment; confirm the configured `JWT_ISSUER` with its operator elsewhere. Never derive a verifier's trusted issuer from an unverified token |
| App slug and public key | Your app's identity in a publisher organization, and the Ed25519 public key its assertions are signed against | You pick the slug when you create the app, then register the key; both need `organization.applications.manage` in that organization — see [Apps and credentials](/identity/apps-and-credentials/#app-identity) |

## Pick a credential

| Your job | Credential | What it proves | Page |
|---|---|---|---|
| A human signs into your app with their WAMP account | OIDC access token and ID token, from authorization code + PKCE | This person is this WAMP user, in this organization | [Sign in with WAMP](/identity/sign-in-with-wamp/) |
| Your backend protects its own API for a signed-in user | Your client's OIDC access token | The user consented to that client and organization; this token does **not** authorize WAMP platform APIs | [Sign in with WAMP](/identity/sign-in-with-wamp/#protecting-your-own-api) |
| Your backend calls WAMP as itself, for one customer organization | App installation access token, obtained by exchanging an app assertion | Your app, installed in that organization, holding those capabilities | [Apps and credentials](/identity/apps-and-credentials/) |
| Your remote MCP service receives the current WAMP principal | Connected-resource identity JWT | Exact resource App, installation, tenant, subject, audience, and origin | [Connected resources](/identity/connected-resources/) |

Two of those are not interchangeable in a way that catches people out. An OIDC
access token identifies a **human**; an app installation token identifies **your
software** acting inside a customer's organization. There is no OAuth
`client_credentials` grant on this platform, so new machine-to-machine access
goes through the app assertion exchange rather than a client secret.

## Account creation, honestly

**There is no self-service sign-up.** New users enter through organization
invitations; no public registration route exists.

The only path onto the platform is **accepting an organization invitation**.
Someone who already holds `organization.members.invite` in an organization
invites an email address; the invite link carries a single-use token in the URL
fragment; opening it in Account Center lets the recipient set a name and
password and become a member in one transaction. Registration is driven by
Account Center itself — the underlying endpoint enforces same-origin against the
Account Center host, so it is not something you can drive with `curl`.

So when you plan onboarding for your integration, plan it as "get invited to an
organization", not "sign up and create an org". Organizations themselves are
created through an operator bootstrap path, not by signed-in users.

One more thing to design around: **`email_verified` is always `false`.** The
claim is released under the `email` scope, but no email-verification flow exists
anywhere in the platform. If you are a relying party, do not gate anything on
that claim, and do not treat a WAMP email address as proven.

## Things developers expect that are not here

| Expected | Reality |
|---|---|
| Client secrets | None exist. A client is either public (`none`) or authenticates with `private_key_jwt` signed by your own Ed25519 key. |
| `client_credentials` grant | Disabled. Use the app assertion exchange. |
| Device authorization flow | Disabled. |
| Dynamic client registration (RFC 7591) | Disabled twice over — the feature is off and the storage adapter refuses. You create clients through the app API instead. |
| Token introspection (RFC 7662) | Disabled. Verify JWTs locally against the JWKS. |
| RS256 / HS256 tokens | Every token this platform signs is **EdDSA** (Ed25519). |

## Before your first call

**There is no single base URL.** WAMP's backend is two independently deployable
processes with disjoint route tables, and a path exists only on the process that
mounts it:

- The **Account** process serves identity (`/oauth2/*`, `/auth/*`, `/api/apps/*`,
  `/api/organizations/*`, `/api/invitations/*`, `/a/:slug/*`) and the metered AI
  proxy as HTTP: `GET /v1/models`, `POST /v1/responses`,
  `POST /v1/chat/completions`. It has no WebSocket upgrade plane; `GET /ws` is
  404.
- The **Cloud** process serves the WAMP Cloud product plane: the rest of `/v1/*`,
  `/ws/cloud/sessions/*`, `/cloud/sessions/*`, git transport, and GitHub
  integration. It authenticates differently and is documented on its own site:
  [docs.cloud.vampikez.fun](https://docs.cloud.vampikez.fun).

Use the Account platform JWKS at `$API/.well-known/jwks.json` for the
platform token contracts documented here. For OIDC, take `jwks_uri` from the
trusted issuer's discovery document. Cloud does not publish a runner JWKS at
that route; its runner machine protocol is separate from app credentials.

`$API` and `$ISSUER` appear throughout these pages as the placeholders described
in [What you need before any code](/identity/overview/#what-you-need-before-any-code).

**Error bodies are not uniform, and you have to code for all three shapes.** They
differ by which layer rejected you:

| Layer | Body | Example |
|---|---|---|
| Authentication middleware | `{"error": "<prose>"}` | `{"error": "Invalid or expired token"}` |
| Account route handlers | `{"success": false, "error": "<machine_code>"}` | `{"success": false, "error": "app_not_found"}` |
| Cloud plane | `{"error": "<machine_code>"}`, no `success` field | `{"error": "cloud_access_denied"}` |

Machine codes are stable and worth branching on. The prose strings are not —
re-authenticate for an expired or invalid credential (`401`); handle permission
refusal (`403`), validation failures, and rate limits separately. Repeating
sign-in does not grant missing authority.

## Where to go next

- [Sign in with WAMP](/identity/sign-in-with-wamp/) — the complete authorization
  code + PKCE flow, claim validation, refresh, logout, and the failures that cost
  the most time.
- [Organizations and roles](/identity/organizations/) — accounts, memberships,
  invitations, the 14 organization permissions, and how product access is
  granted.
- [Apps and credentials](/identity/apps-and-credentials/) — every credential a
  third-party developer can hold, with header format, lifetime, and revocation.