API Trust Boundary Demo

Live interactive security demo

See four real API failure modes with one click.

This page demonstrates a happy path, token expiry, wrong audience, and browser-side schema validation using your live Auth0 tenant and AWS API Gateway endpoint. The interface explains the flow step by step without DevTools.

4Scenarios
Auth0Token issuer
AWSGateway + Lambda
Client-sideValidation layer

This demo was designed and built through a human-led process, with AI used to assist with wording, presentation polish, and code refinement.

Problem and solution

Problem

Securely consuming third-party APIs is hard to explain and easy to get wrong.

Dev teams need to handle tokens, CORS, request validation, and response handling without exposing secrets or turning integrations into brittle one-off scripts.

Solution

This demo simulates secure API integration scenarios in the browser.

It lets teams observe the flow step by step so they can understand how secure API consumption behaves before the real integration is automated in production.

Why it matters

Secure third-party API consumption is easy to get wrong.

Frequency API incidents are common across modern systems.

Imperva found API insecurity accounted for about 1 in 13 cybersecurity incidents globally.

Severity Failures can block access, break trust, and expose data.

This demo shows how token expiry, wrong audience, and unsafe payloads can all stop a request for different reasons.

Business impact Insecure APIs have been linked to major financial losses.

Imperva’s study estimated global annual losses from API insecurity at $41B to $75B, while Akamai reported average incident costs above US$580,000 in surveyed APAC markets.

Sources: Imperva / Marsh McLennan, Akamai, OWASP API Security Top 10

Scenario controls

Interactive

Each button obtains or reuses a token, calls the live API, and explains what happened behind the scenes.

This demo uses a machine-to-machine client credentials flow directly in the browser for demonstration purposes. Auth0 documents the Client Credentials Flow as intended for machine-to-machine applications, and client secrets are meant to remain confidential rather than exposed in browser code. For a production frontend, use a backend or an Authorization Code + PKCE flow instead.

1. Happy scenario

Fetch a valid token, call the protected prices endpoint, and render normalized price rows.

Allowed
1

Request a valid access token from Auth0 using the happy-path client.

2

Send the token in the Authorization: Bearer header to API Gateway.

3

Render the response only after the browser validation checks pass.

2. Expired token

Use the same valid token but wait until it expires, then show the gateway rejection.

401 demo
1

Obtain a valid token and display its expiry.

2

Wait until the token is past its exp timestamp.

3

Call API Gateway again and show that the request is rejected before Lambda is invoked.

3. Wrong audience token

Request a token for a compromised or incorrect audience and prove that API Gateway denies it.

Blocked
1

Get a token whose aud does not match the API Gateway JWT authorizer.

2

Send it to the same protected route.

3

Explain that the gateway denied it because the token was minted for a different API audience.

4. Browser-side validation

Use a sample upstream payload and show how the browser refuses unsafe data before rendering.

Defense in depth
1

Run client-side schema checks against a payload.

2

Accept arrays of items with valid name, price, and currency types.

3

Reject payloads with wrong shapes, wrong types, or suspicious extra fields.

Live output

Idle

This panel records each step so a visitor can follow the flow without reading source code.

Current scenarioNone
Token statusNo token
API resultNo request yet
ValidationNot run

Rendered price data

Name Price Currency
No rows rendered yet.

Technical details

Waiting for interaction...

The Auth0 token call shown here uses the client credentials flow, which is designed for machine-to-machine use rather than browser-based apps. Also note that browsers require proper CORS responses, including allowed origins and headers such as Authorization, for cross-origin token or API requests to succeed.