Try it in the Playground
The AIGW Playground walks through the whole agent flow one request at a time and shows every exchange in full: URL, headers, payload, status code, and response. It's the quickest way to see what How AIGW works looks like on the wire before you write any code.
Open it: https://playground.aigw.eval.loginid.ai/
What is real and what is mocked
The Playground plays the agent. The merchant side is simulated so you don't need a real MCPMCPModel Context Protocol: a standard way for AI agents to call tools and data sources exposed by a server. server or merchant API:
| Component | In the Playground |
|---|---|
| Agent | The Playground page itself |
| Resource MCP (the MCP/UCP service) | Mock — simulated in the browser |
| Resource API (the merchant backend) | Mock — simulated in the browser |
| AIGW discovery, DCR, authorization, token, Proxy token, and credential redemption | Real — calls go to AIGW |
AIGW errors are shown exactly as returned. The page never fabricates a token.
Before you start
You need a Token exchange Resource in AIGW. Open the Environment panel in the top-right corner to set:
| Field | Value | Needed for |
|---|---|---|
| AIGW authorization server | The Resource's Authorization server from its Reference screen, e.g. https://api.aigw.eval.loginid.ai/<RESOURCE_ID>. Also editable on the first step. | All AIGW steps |
| Agent HTTPS callback | Leave blank — it defaults to <playground origin>/oauth/callback | DCR and Authorize |
| Resource indicator | The Resource's Resource indicator / audience | Redeem |
| Resource Auth client ID / secret | A Proxy client from the same Project as the Resource | Proxy auth |
| Resource MCP URL | Leave the mock default | Probe |
Tick Remember to keep the authorization server for next time. Configuration locks once a run starts; press Reset to change it.
The Playground calls the MCP server's credential ResourceResourceThe downstream system registered in a Project. Its kind (Token exchange or OAuth client) decides the role AIGW plays. Auth client. In the AIGW ConsoleAIGW ConsoleThe AIGW developer dashboard (DevCon) where you manage Accounts, Projects, Resources, agents, and policies. it is a Proxy clientProxy clientThe server-side credential (client ID and secret) the MCP/UCP service uses to authenticate itself to AIGW. Never give it to an agent..
Run the flow
Use Run step to send the current step, then Next → to move on. The diagram on the right highlights which parties are talking.
1. Probe — 401 challenge
The agent calls the MCP server with no token. The mock MCP server answers 401 with a WWW-Authenticate header whose resource_metadata points to its Protected Resource MetadataProtected Resource MetadataAn RFC 9728 document an MCP/UCP service publishes to tell agents which authorization server protects it..
2. Discover — Protected Resource Metadata
The agent fetches /.well-known/oauth-protected-resource (RFC 9728). The authorization_servers entry is the per-resource AIGW authorization server you configured.
3. Config — OAuth/OIDC discovery
The agent fetches the real /.well-known/openid-configuration from AIGW. It learns the per-resource authorization endpoint, the core token endpoint, the registration endpoint, and the supported scopes, which include the Resource's own scopes.
4. Dynamic Client Registration
The agent registers itself at POST /api/register. No one had to set it up in advance. AIGW returns 201 with a new client_id and client_secret, plus the domain it derived from the redirect URI and the verification_method (none here, because the Playground doesn't sign with Web Bot AuthWeb Bot AuthAn agent signs its HTTP requests (RFC 9421 HTTP Message Signatures) with keys published in its own signature directory.).
The request deliberately sends no scope. AIGW rejects a DCRDCRDynamic Client Registration (RFC 7591): an agent registers itself as an OAuth client at runtime, with no manual setup. request outright if any requested scope isn't registrable for a dynamic client, so scopes are chosen at the next step.
5. Authorize — real login and PKCE
Pick which discovered scopes to request, then press Continue to AIGW login. The Playground builds an Authorization Code + PKCEPKCEProof Key for Code Exchange: binds an authorization request to the later code exchange so a stolen code is useless. (S256) request to the per-resource authorization endpoint and navigates the browser there.
You sign in on the real AIGW page, using whichever identity providers the Resource allows, and approve the consent screen. AIGW then redirects back to the Playground callback with an authorization code.
Back in the Playground, the Authorize step shows the 302 redirect and the returned code and state.
If authorization is refused right after DCR, the agent may be Pending or Rejected under the ProjectProjectThe isolation boundary for an integration. It holds Resources, agents and agent policy, end users, and Proxy clients.'s Agent policy.
6. Token — real AIGW response
The agent exchanges the code, plus its client_secret and PKCE code_verifier, at the core token endpoint. The response is the unmodified AIGW result: access_token, id_token, refresh_token, and the granted scope. The Playground decodes both JWTs. In the access token, look at:
| Claim | Example | Meaning |
|---|---|---|
iss | https://core.api.aigw.eval.loginid.ai/ | Issued by the core AIGW authorization server |
aud | the Resource indicator | The Resource this token is for |
sub | sub_… | Opaque, per-project user subject |
ext.acr | e.g. …:al2 | How strongly the user was verified (assurance level 2 from the identity verification provider) |
ext.amr | ["mfa", "kba"] | How the user authenticated |
ext.agent / ext.act | client ID, domain, name, verifications | Which agent is acting on the user's behalf |
ext.project_id | Project ID | The Project the token belongs to |
The ID token carries the identity claims the user consented to, such as name, email, and address. Treat it as personal data.
7. Proxy auth — client credentials
Now the Playground plays the MCP server. It authenticates to AIGW with the Proxy client ID and secret (grant_type=client_credentials) and receives a Proxy tokenProxy tokenA short-lived token the MCP/UCP service gets with its Proxy client, sent as X-Proxy-Token when redeeming a merchant token..
8. Redeem — merchant token
The MCP server calls POST /api/credentials/token with the user's AIGW token as Authorization: Bearer, the Proxy token as X-Proxy-Token, and {"resource": "<Resource indicator>"}. AIGW returns the merchant access tokenMerchant access tokenA token issued by the merchant's own authorization server. Only the MCP/UCP service sees it, never the agent. it obtained from the merchant's authorization server during login, with expires_at and the granted scopes. Decode it and you'll see a token issued by the merchant's authorization server (Keycloak in the default Playground Resource), not by AIGW. See Credential redemption.
9. Resource call
The MCP server calls the mock Resource API with the merchant token. The flow is complete.
Troubleshooting the Playground
| Symptom | Likely cause |
|---|---|
| DCR fails with an HTTPS error | The Playground was opened over HTTP. Real AIGW DCR only accepts HTTPS redirect URIs. |
| Authorize is refused | The agent is held or rejected by Agent policy. |
Proxy auth returns 401 | Wrong Proxy client ID/secret, or the Proxy client was revoked. |
| Redeem fails | The Proxy client is from a different Project than the Resource, the Resource indicator doesn't match exactly, or no merchant token was stored because the Resource's merchant authorization server rejected AIGW's assertion. See Troubleshooting. |
Run it yourself
The Playground source is a Vite + React app with a small Node API server. Run it locally with Node.js 22.13 or later:
npm install
npm run dev
Locally you can inspect the UI and discovery. The full login flow needs an HTTPS origin, because AIGW DCR rejects HTTP callbacks. The repository includes npm run dev:tunnel to expose the dev server through a Cloudflare tunnel.