Documentation
Documentation
REST API Requirements
Your resource server must accept and validate XAA-issued Bearer tokens.
Checklist
- Accept
Authorization: Bearer <token>on all protected endpoints - Validate the JWT signature against
https://auth.resource.xaa.dev/jwks(RS256) - Verify
iss=https://auth.resource.xaa.dev - Verify
aud= your resource server URL, exactly as registered (the Auth Server does not normalize trailing slashes — whatever you entered in Wizard Step 1 is what lands in theaudclaim) - Verify
expis in the future - Enforce the required scope per endpoint
- Expose a
/healthendpoint returning HTTP 200 - Allow CORS from the playground origins, or use Proxy Mode
JWT Middleware
CORS
When the Demo makes a direct API call from the browser, you must allow its origin on your server. If you can't add CORS headers, enable Proxy Mode in Step 4 instead. It routes the call server-to-server, bypassing the browser CORS restriction.
The origins to allow are https://xaa.dev (Resource Tester) and https://app.xaa.dev (Requesting App).
Token claims
The access token your server receives:
| Claim | Value |
|---|---|
iss | https://auth.resource.xaa.dev |
aud | Your resource server URL, exactly as registered (no normalization — trailing slash is preserved as-is) |
sub | {providerName}:{userSub} (e.g. customer1:alice@example.com) |
scope | Space-separated granted scopes |
app_org | Provider (tenant) name that authenticated the user |
exp | Expiry (Unix timestamp) |
The access token header uses typ: at+jwt (RFC 9068). If your JWT library enforces a specific typ, configure it to accept at+jwt.
A token whose identity came from a SAML assertion carries an extra structured sub_id claim, and you must resolve the user from it rather than sub. See REST API Requirements (SAML).
Next step
Ready to test? Open Test Your Resource App, register your server, and run the 4-step XAA flow against it. See the Testing Guide for a detailed walkthrough.
On this page