API Tools & Backend Utilities
Browser-based tools for JWT encoding and validation, OAuth token inspection, API key generation, HMAC request signing, and webhook payload verification. No data is uploaded or stored — every operation runs locally in your browser.
6 tools covering authentication tokens, API keys, webhook security, and request signing.
Building Secure APIs: What You Need to Know
Every production API depends on at least three things: a reliable way to verify who is calling it, a mechanism to ensure that request payloads have not been tampered with in transit, and controls that prevent a single caller from overwhelming the system. Getting any one of these wrong leads to real consequences — leaked credentials, forged requests, or availability incidents. The tools and reference material on this page cover each layer.
API Testing and Debugging
Before writing a line of integration code, test the endpoint directly. Inspecting the raw HTTP response — status codes, headers, response body, and latency — tells you whether the API behaves as documented. Most authentication problems, rate-limit issues, and serialisation mismatches surface at this stage. A browser-based API tester lets you iterate quickly without switching to a separate desktop application.
Authentication: API Keys, JWTs, and OAuth
API keys are opaque credentials — a random string the server associates with a caller. They are simple to issue and easy to revoke, making them ideal for server-to-server integrations where you control both sides. The risk is that a leaked key grants full access until rotated; store them in environment variables or secrets managers, never in source code.
JWTs (JSON Web Tokens) are self-describing tokens that carry claims — user ID, roles, expiry, issuer — in a signed payload. The server validates the signature and checks the claims without a database lookup, making JWTs well-suited for stateless microservices. The tradeoff is that a JWT cannot be revoked before its expiry without a token blocklist. Use short expiry times (15 minutes for access tokens) and a refresh token pattern for long-lived sessions. See API Key vs JWT for a detailed comparison.
OAuth 2.0 solves a different problem: delegated authorisation. A user grants a third-party application permission to act on their behalf without sharing their password. The application receives a scoped access token valid for a limited time. When you also need to authenticate the user — confirm who they are, not just what they can do — layer OpenID Connect (OIDC) on top of OAuth 2.0. OIDC adds an ID token carrying the user's identity claims alongside the access token.
Webhook Verification and HMAC Request Signing
A webhook delivers events to your server over HTTP. Without verification, any actor can POST a forged payload to your endpoint. Providers such as GitHub, Stripe, and Shopify mitigate this by signing the request body with HMAC-SHA256 using a shared secret. Your server recomputes the same HMAC and rejects requests where the signatures do not match. The comparison must use constant-time equality to prevent timing attacks. See How HMAC API Signing Works for a full walkthrough including replay-attack prevention with timestamps.
JWT signing uses the same HMAC primitive: HS256 is HMAC-SHA256 over the base64url-encoded header and payload. The difference is that JWTs are produced and consumed by the same service (or services sharing a secret), while HMAC request signing is typically used between two services that agreed on a shared key during integration setup. For non-repudiation — proving that a message was signed by the holder of a specific private key — use an asymmetric algorithm such as RS256 (RSA) or ES256 (ECDSA) instead.
Rate Limiting and Transport Security
Rate limiting protects your API from abuse, cost overruns, and availability incidents caused by a single runaway caller. Common algorithms include fixed window, sliding window, token bucket, and leaky bucket — each with different burst characteristics. Apply limits at the API gateway or load balancer layer, not deep inside application code, so they cannot be bypassed. See API Rate Limiting Explained for algorithm trade-offs and enforcement strategies.
All API traffic should run over TLS 1.2 or 1.3. TLS provides confidentiality, integrity, and server authentication for data in transit — without it, tokens and API keys are trivially intercepted on any shared or monitored network. TLS 1.0 and 1.1 are deprecated and disabled in all current browsers. See What Is TLS? for a practical explanation of the handshake and certificate trust.
API & Backend Tools
All tools run entirely in your browser. No data is sent to any server.
API Testing & Debugging
Inspect HTTP requests, test endpoints, and debug API responses before integrating.
Authentication & Token Tools
Decode, validate, sign, and inspect JWTs and OAuth tokens. Verify claims, expiry, and signatures without sending data to any server.
Webhooks & Request Signing
Verify incoming webhook payloads, detect providers, and compute HMAC signatures for request signing.
API Guides & Comparisons
Authoritative reference pages to help you choose the right authentication method, understand token trade-offs, and avoid common API security mistakes.
Guides
A practical guide to API authentication — understand API keys, JWT, OAuth 2.0, and HMAC request signing, when to use each, and how to choose the right approach.
A practical guide to HMAC API signing — how to sign requests with a shared secret, prevent replay attacks with timestamps, and verify webhook payloads from Stripe, GitHub, and AWS.
API rate limiting controls how many requests a client can make in a given window. Covers fixed window, sliding window, token bucket, and leaky bucket algorithms, where to enforce limits, and common mistakes.
Understand the full JWT authentication flow — token structure, signing algorithms (HS256 vs RS256 vs ES256), refresh token patterns, and the vulnerabilities that break most implementations.
Comparisons
API keys are simple and easy to revoke; JWTs are stateless and carry embedded claims. Compare their trade-offs and learn which to use for your use case.
JWTs are stateless and self-contained; session cookies require server-side storage but offer easy revocation. Compare trade-offs and learn which to choose for your auth system.
API keys are simple opaque credentials suited for server-to-server calls; OAuth delegates user authorization without sharing passwords. Compare use cases, complexity trade-offs, and migration considerations.
OAuth 2.0 handles authorization (access tokens); OIDC adds authentication (ID tokens, user identity) on top. Understand when you need both and the implementation mistakes that mix them up.
Frequently Asked Questions
Which authentication method should I use for my API?
It depends on your use case. Use API keys for simple server-to-server integrations where you control both sides — they are easy to issue and revoke. Use JWTs when you need stateless tokens with embedded claims (user ID, roles, expiry) that can be validated without a database lookup. Use OAuth 2.0 when delegating access on behalf of users — letting third-party apps act without sharing passwords. Use HMAC signing when request integrity and replay-attack prevention matter most, as in AWS Signature Version 4 or webhook verification.
What is a JWT and how is it validated?
A JSON Web Token (JWT) is three base64url-encoded segments joined by dots: header.payload.signature. The header specifies the algorithm (HS256, RS256, ES256). The payload carries claims — sub (subject), iss (issuer), exp (expiry), and any custom fields. The signature is a cryptographic MAC or digital signature over the header and payload. Validation means verifying the signature against the known secret or public key, checking that exp has not passed, and confirming iss and aud match the expected values.
What is the difference between OAuth 2.0 and OpenID Connect?
OAuth 2.0 is an authorisation framework — it issues access tokens that grant permission to resources (scopes) but says nothing about who the user is. OpenID Connect (OIDC) is an authentication layer built on top of OAuth 2.0. It adds an ID token — a JWT carrying user identity claims like sub, email, and name — and a standard UserInfo endpoint. Use OAuth alone for API access delegation; add OIDC when you also need to authenticate and identify the user.
How does HMAC webhook verification work?
The provider hashes the raw request body (and sometimes a timestamp) using HMAC-SHA256 with a shared secret, then sends the resulting signature in a header — for example, X-Hub-Signature-256 (GitHub) or Stripe-Signature. On receipt, you recompute the same HMAC over the same input and compare using constant-time equality. Any mismatch means the payload was not signed by the expected party or was modified in transit. Use the Webhook Signature Verifier to compute and verify HMAC signatures in your browser.
Can I verify a webhook signature without a server?
Yes, for providers that sign the raw body directly — GitHub uses HMAC-SHA256 with a sha256= prefix; Shopify uses HMAC-SHA256 base64-encoded. Both can be verified in the browser using the Web Crypto API. Stripe and Slack are exceptions: they sign a combined string that includes a timestamp from a separate header, so body-only verification is not possible without that header value. The Webhook Validator on this page detects the provider automatically and handles what can be done browser-side.
Why should I rotate API keys and how often?
API keys are long-lived credentials that never expire on their own. Rotation limits the exposure window if a key is leaked. A rotated-out key loses access immediately. Rotate keys: after any suspected breach, when a team member with key access leaves, on a scheduled basis for high-sensitivity integrations, and whenever a key appears in a log file, error message, or version-control commit. The API Key Generator on this page creates cryptographically random keys ready for immediate use.
What is API rate limiting and which algorithm should I use?
Rate limiting caps the number of requests a client can make in a given time window to prevent abuse, protect backend capacity, and control costs. Fixed window is the simplest — a counter resets at regular intervals, but clients can burst at window boundaries. Sliding window smooths this out by tracking requests within a rolling period. Token bucket allows controlled bursts: tokens accumulate at a fixed rate up to a maximum, and each request consumes one. Leaky bucket enforces a strict output rate regardless of input bursts. For most APIs, sliding window or token bucket is the right choice.