Forem: Blue Hills

Auth regression tests for CI: what to assert and why

Blue Hills — Sun, 03 May 2026 16:36:05 +0000

Most teams I have worked with have one auth test in their suite. It looks like this:

test('valid token verifies', () => {
  const token = signSync({ sub: 'user-1', aud: 'api://backend' }, secret);
  const result = verify(token, options);
  expect(result.valid).toBe(true);
});

That test is fine. It is also a smoke test, not a regression suite. It catches the case where verification is completely broken. It does not catch the case where verification accepts tokens that should be rejected — which is most of the auth bugs that ship to prod.

A real auth regression suite asserts that invalid tokens fail with the right code. Each test pairs a token with the failure mode it should produce. If the policy quietly accepts a token that should fail, the suite fails the PR. The audience configuration drift becomes visible the moment it's introduced, not three quarters later when someone writes the post-incident review.

Here is the assertion catalog that has caught real bugs in real services.

Pattern 1: Wrong audience

A token issued for service A should not authenticate against service B, even when both trust the same issuer. This is the most common configuration drift in microservice auth.

- token: <token issued for api://reporting>
  policy:
    issuer: https://login.example.com
    audiences: [api://billing]
    allowed_algs: [RS256]
  expected_failure_codes: [AUDIENCE_MISMATCH]

If your billing service accepts a reporting-audience token, a reporting-audience credential becomes a billing credential. The fix is one config line. The test ensures the config line stays correct after the next refactor.

Pattern 2: Expired token

A token whose exp claim is in the past must be rejected. Allow a small clock skew (60 seconds is typical) but no more.

- token: <token with exp = now() - 5 minutes>
  policy:
    issuer: https://login.example.com
    audiences: [api://backend]
    allowed_algs: [RS256]
    clock_skew_seconds: 60
  expected_failure_codes: [TOKEN_EXPIRED]

The bug this catches: a verifier that compares exp against the wrong clock (server-side vs UTC vs local timezone), or that skips expiry checking entirely when exp is missing.

Pattern 3: `alg=none`

An attacker sets "alg":"none" in the JWT header and ships an unsigned token. If your verifier accepts the token's own alg claim instead of using an explicit allowlist, the token will pass.

- token: <token with header.alg = none, no signature>
  policy:
    issuer: https://login.example.com
    audiences: [api://backend]
    allowed_algs: [RS256]
  expected_failure_codes: [ALGORITHM_NOT_ALLOWED]

This bug is eleven years old and still in production. Every JWT library has a way to fall into it. The regression test is the only thing that ensures your verifier is not in the family that does.

Pattern 4: Algorithm confusion (RS256 → HS256)

An attacker takes a token signed with RS256 (asymmetric) and re-signs it with HS256 (symmetric) using the public key as the shared secret. Some verifiers accept both algorithms with the same key material, and the public key happens to be valid as an HS256 secret.

- token: <token re-signed with HS256 using RS256 public key as secret>
  policy:
    issuer: https://login.example.com
    audiences: [api://backend]
    allowed_algs: [RS256]
  expected_failure_codes: [ALGORITHM_NOT_ALLOWED]

This test catches the bug class explicitly: even if your verifier code looks correct, the test ensures HS256 is rejected when only RS256 should be allowed.

Pattern 5: Wrong issuer

A token from https://login.legitimate.com should not authenticate against https://login.attacker.com or vice versa. The check has to be exact-match — no prefix substring, no glob.

- token: <token with iss = https://login.attacker.com>
  policy:
    issuer: https://login.legitimate.com
    audiences: [api://backend]
    allowed_algs: [RS256]
  expected_failure_codes: [ISSUER_MISMATCH]

The test catches verifiers that do iss.startsWith(expected) or fuzzy hostname comparison. Both have shipped in production. Both let attacker-issuer tokens through.

Pattern 6: Missing required claim

If your service requires a tenant_id claim, a token without it must be rejected.

- token: <token without tenant_id claim>
  policy:
    issuer: https://login.example.com
    audiences: [api://backend]
    allowed_algs: [RS256]
    required_claims: [sub, tenant_id]
  expected_failure_codes: [REQUIRED_CLAIM_MISSING]

The test catches drift where a new claim is added to your service's contract but the verifier config wasn't updated to require it.

Pattern 7: Forged signature

A token whose signature does not match the public key — anything from a copy-paste truncation to an active forgery — must be rejected.

- token: <token with signature segment replaced with garbage>
  policy:
    issuer: https://login.example.com
    audiences: [api://backend]
    allowed_algs: [RS256]
  expected_failure_codes: [SIGNATURE_INVALID]

This is the smoke test in disguise. Every verifier should pass it. Run it anyway — the day it fails is the day someone replaced your verifier with a stub.

Pattern 8: JWKS rotation drift

The verifier should pick up new keys after the issuer rotates. If a token signed with a new key returns KID_NOT_FOUND instead of pass, the cache is stale and your fleet is about to break.

- token: <token signed with key issued AFTER last cache refresh>
  policy:
    issuer: https://login.example.com
    audiences: [api://backend]
    allowed_algs: [RS256]
  expected_failure_codes: []   # should pass — verifier should refetch JWKS

This is the test we run in CI nightly. If it ever fails, JWKS rotation just happened and our cache is now stale; the fix is to force a JWKS refetch in our verifier.

Wiring it into CI

The eight patterns above run as a single batch in jwtshield's /v1/test/auth-regression endpoint. The endpoint accepts a list of (token, policy, expected_failure_codes) tuples and returns a suite-level pass/fail plus per-check structured findings.

- uses: redbullhorns/jwtshield-ci@v1
  with:
    issuer: https://login.example.com
    audience: api://backend
    fail-on-severity: high
    api-key: ${{ secrets.JWTSHIELD_API_KEY }}

The Action runs in roughly 800ms. It costs nothing on the free tier (200 verifies per month). It uses synthetic test tokens — never your production tokens. The audit trail lives at https://jwtshield.com/runs/<id> if you want compliance evidence.

What makes this different from a smoke test

A smoke test confirms verification works. A regression suite confirms verification rejects what it should — including the bug classes that have shipped to production for the last decade. The cost of writing the eight patterns is one afternoon. The cost of skipping them is one outage.

Get an API key → — or browse the GitHub Action listing.

Discuss on: Hacker News · dev.to · Hashnode · Mastodon

Related:

JWT verification in production: an 8-check field guide

Blue Hills — Sun, 03 May 2026 16:31:40 +0000

A correct JWT verifier does eight things. Most production verifiers I have read do four or five of them. The other three or four get skipped because the library defaults aren't loud about them, the docs gloss over them, or someone copied a "it works" snippet from Stack Overflow circa 2018.

Here is the full eight-check list, what each one prevents, and what it looks like to implement them with structured error codes — the kind that survive a midnight 401 incident with a clear remediation path.

1. Signature

Verify the cryptographic signature against a public key from the issuer's JWKS endpoint, scoped to the kid (key id) in the JWT header.

Fails if: signature is forged, key has been rotated and your cache is stale, or the JWKS endpoint is unreachable. The bug class is anything that lets a token through without signature verification — the alg=none family, or libraries that accept the token's own alg claim instead of an explicit allowlist.

Failure code: SIGNATURE_INVALID or KID_NOT_FOUND.

2. Issuer (`iss`)

Match the token's iss claim against your expected issuer URL, exactly. No prefix-substring tricks. No "starts with https://login." — that lets https://login.attacker.com through.

Fails if: the token came from a different issuer, the issuer rebranded its hostname (acquisition, region split), or your config has a typo. The third case is the silent failure mode — your tests pass against your test issuer, but production talks to a different one and you never noticed.

Failure code: ISSUER_MISMATCH.

3. Audience (`aud`)

Match the token's aud claim against your service's expected audience, exactly. The audience names which service the token is intended for. Skipping this check is the difference between "we have authentication" and "we have authorization" — without it, a token issued for api://billing will authenticate against api://reporting because both trust the same issuer.

Fails if: the token was issued for a different service, or your config doesn't pin the audience at all. The "doesn't pin" case is the most common production bug. New endpoints get added; the audience check stays missing.

Failure code: AUDIENCE_MISMATCH.

4. Algorithm allowlist (`alg`)

Specify allowed algorithms explicitly. Reject everything else. If you only ever issue HS256, your verifier must reject HS512, RS256, PS512, none, and every other algorithm — even though they are valid JWT algorithms.

This is the check that prevents the alg=none bug class and the RS256→HS256 confusion attack (where an attacker re-signs a token with the public key as if it were a shared secret). Both attacks are eleven years old and still in production.

Fails if: the token's alg is not in your allowlist, or the allowlist is too permissive (e.g., includes both RS256 and HS256 with the same key material).

Failure code: ALGORITHM_NOT_ALLOWED.

5. Time (`exp`, `nbf`, `iat`)

Check that:

exp (expiration) is in the future,
nbf (not before) is in the past or absent,
iat (issued at) is plausible (not 5 years ago, not in the future).

Allow a small clock skew (typically 60 seconds) to handle the inevitable NTP drift across nodes. Larger skew is a smell — it usually means someone hit "valid token rejected because clock drift" once and over-corrected.

Fails if: the token is expired, not yet valid, or backdated implausibly.

Failure code: TOKEN_EXPIRED, TOKEN_NOT_YET_VALID, IAT_IMPLAUSIBLE.

6. Required claims

Beyond the standard claims, your service may require certain custom claims to be present. A sub (subject) is almost always required. A tenant_id claim might be required for multi-tenant systems. A scopes claim might gate access to specific endpoints.

Required-claim checks are not built into JWT libraries — they are a contract between your verifier and your issuer. The contract has to be written down somewhere, and the verifier has to enforce it.

Fails if: a required claim is missing or has the wrong type.

Failure code: REQUIRED_CLAIM_MISSING, CLAIM_TYPE_MISMATCH.

7. JWKS reachability

The verifier needs to fetch the JWKS endpoint to get public keys. If the endpoint is unreachable — DNS failure, certificate expired, 5xx response, network partition — you have a binary choice: fail closed (reject all tokens until JWKS is fetchable) or fail open (accept tokens with cached keys, eventually run out of cache).

Most libraries fail open. That means a JWKS endpoint outage on the issuer side gives you minutes-to-hours of "tokens still verify, but we have no idea if they're still valid keys." This is fine for short outages. It is a security incident for long ones.

Fails if: JWKS endpoint returns 5xx, has TLS issues, or DNS-resolves to something unexpected.

Failure code: JWKS_UNREACHABLE, JWKS_TLS_ERROR, JWKS_DNS_FAILURE.

8. OIDC discovery integrity

If you trust the OIDC discovery document (/.well-known/openid-configuration) to tell you the issuer, JWKS URI, and supported algorithms, you need to verify that the discovery document is consistent with what your verifier expects. The most common drift modes:

The issuer changes hostnames. Tokens carry the new hostname, your verifier expects the old one.
The supported algorithms change. The issuer deprecates RS256 in favor of ES256.
The JWKS URI moves. Your cached JWKS goes stale because the polling URL no longer returns keys.

Pin the discovery document. Re-validate against it on every deploy, not on first call.

Fails if: discovery document fields don't match your verifier's pinned config, or have moved without your config catching up.

Failure code: DISCOVERY_DRIFT, JWKS_URI_MISMATCH, ALG_POLICY_DRIFT.

What this looks like in production

A correct verifier returns structured findings, not boolean true/false. For each check, emit:

{
  "valid": false,
  "statuses": {
    "signature": "pass",
    "issuer": "pass",
    "audience": "fail",
    "algorithm": "pass",
    "time": "pass",
    "required_claims": "pass"
  },
  "findings": [
    {
      "code": "AUDIENCE_MISMATCH",
      "severity": "high",
      "message": "Token audience 'api://reporting' does not match expected 'api://billing'",
      "remediation": "Update verifier config to accept 'api://reporting' OR reject this token"
    }
  ]
}

The structured output is what makes JWT bugs debuggable. A boolean rejection tells you a token failed. A structured rejection tells you which check failed, why, and what to do about it.

Skip-the-implementation option

If you do not want to wire all eight checks yourself, this is what jwtshield's /v1/validate/jwt endpoint runs on every call. Pass a token and a policy; get a structured VerifyResult back. The endpoint runs all eight checks every time, with consistent failure codes across all your services.

In CI, drop the GitHub Actions wrapper into any workflow:

- uses: redbullhorns/jwtshield-ci@v1
  with:
    issuer: https://login.example.com
    audience: api://backend
    allowed-algs: RS256
    fail-on-severity: high
    api-key: ${{ secrets.JWTSHIELD_API_KEY }}

Five lines. Eight checks. Structured findings. Free tier covers 200 verifies per month.

Get an API key →

Discuss on: Hacker News · dev.to · Hashnode · Mastodon

Related:

We rotated our JWKS without overlap. Here is the 4-minute window that broke prod.

Blue Hills — Sun, 03 May 2026 16:31:34 +0000

The on-call alert at 02:14 said auth_5xx_rate spiked from 0.01 to 31.4. Not a deploy window. Not a traffic spike. Just thirty-one percent of authenticated requests failing for ~four minutes, then back to baseline.

The cause was a JWKS rotation on the issuer side. New keys came in. Old keys went out. Caches in our service didn't refresh fast enough. Tokens signed with the new key were rejected because the verifier still held the old JWKS. Tokens signed with the old key were rejected because the issuer had stopped publishing them. We had a key-overlap gap of roughly four minutes between when the issuer stopped issuing tokens with the old key and when our verifier's cache picked up the new one.

This is a class of bug that does not show up in any of the tests we run. Unit tests use a fixture JWKS that never rotates. Integration tests use a mocked issuer. Synthetic monitoring hits the live issuer but uses tokens minted within the same minute, so cache freshness is irrelevant. The bug only shows up in the seam between the issuer's rotation cadence and the verifier's cache TTL — a seam that exists only in production.

The mechanic

Identity providers rotate signing keys for two reasons: scheduled rotation (typically 24h to 30 days, depending on policy) and incident rotation (compromise suspected). The standard practice is overlap — publish the new key in the JWKS endpoint several hours before issuing tokens with it, so every consumer's cache has time to refresh before the first token signed with the new key arrives.

The overlap window has to be longer than the longest cache TTL across all consumers. Most JWKS-fetching libraries default to a 10-minute TTL. Some are 1 hour. Some hardcode a 24-hour cache and don't expose a refresh hook at all. If your overlap is shorter than your slowest consumer's TTL, you will see exactly what we saw: a brief window where new tokens are unverifiable because the consumer hasn't picked up the new key yet.

Our issuer's overlap was 4 hours. The consumer with the slowest cache was a service we hadn't touched in six months, running an older version of node-jose with a 24-hour TTL. The first token signed with the new key arrived 4 hours and 12 seconds after the rotation announcement. Cache TTL hadn't expired yet. 401s for the rest of the cache window.

The reproduction

Spin up a JWKS server. Sign a token with key A. Verify it. Rotate the JWKS endpoint to key B with no overlap. Sign a new token with key B. Try to verify with the cached JWKS:

ERR: kid 'b1' not found in JWKS
ERR: signature verification failed

That is the exact production error, just on a laptop. The painful part of the production version is that you cannot fix it from inside the verifier — by the time the alert pages, the rotation is already happening, and the only mitigation is to wait for the cache TTL to expire across the fleet.

What we actually did

After the postmortem, three things changed:

1. Fail loud, not silent. We added explicit logging when the cache misses on a kid lookup, and when JWKS refresh returns a different fingerprint than the cached one. The 4-minute window had been silent in our logs because the JWT library swallowed the cache miss and returned a generic "signature invalid" error. We could not tell from logs alone that this was a rotation problem.

2. Forced refresh on kid miss. Most JWT libraries don't refresh the JWKS when they hit a kid they don't recognize — they fail closed and return an error. We patched our wrapper to force a JWKS refetch on the first kid miss, then retry verification once. This shortens the window from "wait for cache TTL" to "one refetch round-trip" — sub-second for most clients.

3. We added a CI check. Every deploy now runs a JWKS rotation classifier against our issuer. If the issuer's current JWKS is disjoint from the previous JWKS we recorded — meaning no key in the previous set is in the current set — the CI step fails the build with a structured finding. This is the check that would have caught the issuer-side overlap gap before anyone shipped tokens against it.

The check we use is jwtshield's /v1/validate/jwks-rotation endpoint. It accepts a previous JWKS, a current JWKS, an optional sample token, and an optional overlap policy. It returns one of no_change, safe_overlap, overlap, or disjoint. disjoint means: every key has changed, no overlap window. That is the failure mode.

curl -X POST https://api.jwtshield.com/v1/validate/jwks-rotation \
  -H "Authorization: Bearer $JWTSHIELD_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "previous_jwks": <last-known good>,
    "current_jwks":  <freshly fetched>,
    "overlap_policy": { "min_overlap_count": 1 }
  }'

In CI, the redbullhorns/jwtshield-ci@v1 Action wraps this into a 5-line GHA step:

- uses: redbullhorns/jwtshield-ci@v1
  with:
    issuer: https://login.example.com
    audience: api://backend
    fail-on-severity: high
    api-key: ${{ secrets.JWTSHIELD_API_KEY }}

The step fails the build if the rotation classifier returns disjoint (no overlap), or if the overlap policy you set is violated. If the issuer is well-behaved and overlaps are 24h+, you never see this fire. The day someone forgets to set the overlap correctly, you find out before tokens ship.

What we learned

JWKS rotation is one of those bugs that is invisible until it ruins your night. Test fixtures don't replicate the seam. Mocked issuers don't either. The bug lives in the gap between the issuer's rotation policy and your verifier's cache TTL, and it stays invisible until the gap is shorter than the cache.

The postmortem item that made the difference wasn't the cache fix or the logging change — those were good, but they shorten the blast radius once the bug fires. The CI check is what stops the bug from firing in the first place.

If you've shipped a JWT validator in the last five years and you have not run jwks-rotation against your issuer's last 30 days of JWKS publications, you have at least one of these gaps in your fleet right now.

Read the full incident-class catalogue: Three JWT bugs that ship to prod silently.

Free tier: 200 verifies per month, all algorithms, no card. Get an API key →

Discuss on: Hacker News · dev.to · Hashnode · Mastodon

Related:

Three JWT bugs that ship to prod silently — and the 5-line CI test that catches them

Blue Hills — Sat, 02 May 2026 15:16:32 +0000

Your auth tests pass. Your token verification works. Then your identity provider rotates a key at 02:47, your service hasn't refreshed its JWKS cache for 12 hours, and 8 minutes of production traffic hits 401.

Or worse: the rotation does happen, your cache picks up the new keys, but a service you haven't touched in six months is still pinning the old kid. Now half your fleet validates and half rejects, your error budget bleeds, and the only signal in your dashboard is "auth failures up."

This is the silent-bug class. Your unit tests don't cover it because the tokens you generate in tests don't drift. Your integration tests don't cover it because mocked issuers are eternal. Snyk doesn't catch it because it's not a vulnerability in your code — it's a configuration that goes stale between your last deploy and the moment it matters.

We built jwtshield to catch the three concrete failure modes that take down OIDC in production. Add a five-line GitHub Actions step. Each bug below is a real incident class with a reproduction and a one-line mitigation in CI.

Bug 1: JWKS rotation without overlap

Your identity provider publishes signing keys at https://login.example.com/.well-known/jwks.json. Your service caches that JWKS for some interval (10 minutes? An hour? Whatever your library defaults to). Tokens are signed by the current private key; verification uses the matching public key from the cache.

The provider rotates keys. Best practice is to publish the new key 24-48 hours before issuing tokens with it, so caches everywhere have time to pick it up. This is "overlap." Without it, the moment the provider switches signing keys, every cached JWKS in the world is stale until it refreshes.

Most identity providers do overlap correctly. Some don't. Some teams misconfigure their own internal IdPs. The result is a ~3-minute window where new tokens reference a kid that no verifier has seen yet.

Reproduction. Spin up a JWKS server. Sign a token with key A. Verify it. Rotate the JWKS endpoint to key B with no overlap. Sign a new token with key B. Try to verify with the cached JWKS. You'll see one of two failures:

ERR: kid 'b1' not found in JWKS
ERR: signature verification failed

The check. jwtshield's /v1/validate/jwks-rotation accepts a previous JWKS, a current JWKS, an optional sample token, and an optional overlap policy. It returns one of no_change | safe_overlap | overlap | disjoint. disjoint means: no key from the previous set is in the current set. That's the failure mode.

curl -X POST https://api.jwtshield.com/v1/validate/jwks-rotation \
  -H "Authorization: Bearer $JWTSHIELD_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "previous_jwks": <last-known good>,
    "current_jwks":  <freshly fetched>,
    "overlap_policy": { "min_overlap_count": 1 }
  }'

If you run this on every deploy of the service that owns the issuer config, you catch the rotation gap before it ships.

Bug 2: Wrong audience claim

The aud claim in a JWT names the service the token is intended for. A token issued for api://billing should not authenticate against api://reporting. This is the audience check, and it is the difference between "we have auth" and "we have authorization."

The bug: a service accepts any well-signed token from a trusted issuer, regardless of aud. A user signs in to billing, billing issues a token, the user replays the token against reporting, and reporting hands back the user's data. The signature is valid. The expiry is fresh. The issuer is on the allowlist. The only thing wrong is that this token was never meant for this service.

This is a configuration bug. The verifier on reporting was set up six quarters ago by an engineer who has since left, and it doesn't pin the audience. New endpoints get added; the audience check stays missing.

Reproduction. Use any JWT library that accepts an "issuer" but not an "audience" parameter. Issue a token from your IdP for service A. Send it to service B. Most setups let it through.

The check. jwtshield's /v1/test/auth-regression accepts a list of (token, expected_failure_codes) tuples and runs them against your policy. Add one entry per service:

- token: <token issued for api://reporting>
  policy:
    issuer: https://login.example.com
    audiences: [api://billing]
    allowed_algs: [RS256]
  expected_failure_codes: [AUDIENCE_MISMATCH]

The suite passes only if the token correctly fails with AUDIENCE_MISMATCH. If the policy quietly accepts it, the suite fails the PR. The audience configuration drift becomes visible the moment it's introduced.

Bug 3: Issuer config drift (the OIDC discovery doc lies)

Every OIDC provider exposes a discovery document at /.well-known/openid-configuration. It lists the issuer URL, JWKS URI, supported algorithms, and the endpoints clients need. Your service reads it once at startup, caches the values, and verifies tokens against the cached config.

The provider updates the discovery doc. The cached config is now stale. The most common drift modes:

The issuer changes hostnames (acquisition, rebrand, region split). Tokens carry iss: https://new.example.com, your verifier expects https://old.example.com, validation fails.
The supported algorithms change. The provider deprecates RS256 in favor of ES256. Your verifier accepts both, so tokens still validate, but the policy you intended to enforce is now wrong.
The JWKS URI moves. Your cached JWKS goes stale because the polling URL no longer returns keys.

Reproduction. Set up a verifier that caches the discovery doc on first call. Update the discovery doc on the provider side. Wait for the next token request. Validation passes against stale config until something visible breaks.

The check. jwtshield's /v1/lint/oidc-config takes the issuer URL, expected audiences, allowed algorithms, JWKS URI, and redirect URIs. It fetches the live discovery doc, fetches the live JWKS, and emits structured findings:

{
  "valid": false,
  "findings": [
    {
      "code": "JWKS_URI_MISMATCH",
      "severity": "high",
      "message": "Configured JWKS URI does not match discovery document",
      "evidence": {
        "configured": "https://login.example.com/.well-known/jwks.json",
        "discovered": "https://login.example.com/oauth/jwks"
      },
      "remediation": "Update your verifier configuration to use the discovered URI..."
    }
  ]
}

Run it nightly against your prod issuer. The first time the discovery doc moves, you find out before your customers do.

The fix: five lines of CI

All three checks ship in jwtshield-ci, our GitHub Actions wrapper. Add this to any workflow that touches your auth path:

- uses: redbullhorns/jwtshield-ci@v1
  with:
    issuer: https://login.example.com
    audience: api://backend
    fail-on-severity: high

The Action calls jwtshield's regression suite with your policy, prints a structured status table, and fails the build on any high-severity finding. It runs in roughly 800ms. It costs nothing on the free tier (200 verifies/month).

We send synthetic test tokens, never your production tokens. Tokens are validated in memory and discarded — zero retention. Your audit trail lives at https://jwtshield.com/runs/<id> if you want compliance evidence.

The full status table on a passing run:

◼ jwtshield-ci v1.0.0 ─────────────────────────────────
  signature:        ✓ PASS
  issuer:           ✓ PASS
  audience:         ✓ PASS
  algorithm:        ✓ PASS
  time:             ✓ PASS
  required_claims:  ✓ PASS
  ─────────────────────────────────────────────────────
  6/6 checks passed · 0 findings
  evidence: https://jwtshield.com/runs/abc123def456

Try it

Free tier: 200 verifies per month, all algorithms, community support. No credit card.

# 1. Get a key
open https://jwtshield.com/signup

# 2. Run the rotation classifier locally
curl -X POST https://api.jwtshield.com/v1/validate/jwks-rotation \
  -H "Authorization: Bearer $JWTSHIELD_API_KEY" \
  -H "Content-Type: application/json" \
  -d @rotation.json

# 3. Add the Action to your CI
# .github/workflows/auth.yml
- uses: redbullhorns/jwtshield-ci@v1
  with:
    issuer: https://login.example.com
    audience: api://backend
    fail-on-severity: high

Pricing: $0 Starter (200 verifies, 1 issuer) → $49 Developer → $99 Startup → $199 Team → custom Enterprise. The Team tier covers 50,000 verifies a month, 25 issuers, full CI regression suite, and 30-day evidence retention.

If you've shipped a JWT validator in the last five years, you have at least one of these three bugs latent in production. The check is five lines.

Discuss on: Hacker News · dev.to · Hashnode · Mastodon

Related:

Stop Sending Raw Clinical Notes to Your AI Stack

Blue Hills — Wed, 08 Apr 2026 17:45:56 +0000

Clinical Note De-identifier API: De-Identify Clinical Notes Before AI Processing

A privacy-first API for healthcare developers building LLM, analytics, and search workflows

If you’re building healthtech software with LLMs, clinical text processing, medical note summarization, analytics, or search pipelines, you’ve probably run into the same problem:

clinical notes are incredibly useful — and incredibly sensitive.

They contain names, dates, phone numbers, addresses, MRNs, IDs, and other patient-identifiable information that should not casually flow through every downstream service in your stack.

That creates friction for developers.

You want to:

summarize notes with AI
classify records
extract insights
build internal tooling faster

But before any of that, you need a clean way to de-identify the text.

That is exactly why I built Clinical Note De-identifier.

It is now publicly listed on RapidAPI as Clinical Note De-identifier, which makes it easier for developers to discover the API, review the listing, and integrate it into their own workflows through the RapidAPI marketplace listing.

What the Clinical Note De-identifier API does

Clinical Note De-identifier is an API that helps remove or mask sensitive information from clinical note text before it moves into downstream systems.

Think of it as a preprocessing layer for healthcare-adjacent developer workflows.

You send in raw note text like this:

Patient: John Doe
DOB: 04/14/1982
MRN: 842991
Seen at North Valley Clinic on 03/21/2026.
Phone: 555-123-8841

Assessment:
Patient reports worsening lower back pain for the last 3 weeks...

And get back de-identified output like this:

Patient: [REDACTED_NAME]
DOB: [REDACTED_DATE]
MRN: [REDACTED_ID]
Seen at [REDACTED_LOCATION] on [REDACTED_DATE].
Phone: [REDACTED_PHONE]

Assessment:
Patient reports worsening lower back pain for the last 3 weeks...

The goal is simple:

preserve the clinical value of the note while reducing exposure of sensitive identifiers.

Why this matters for healthcare developers

A lot of API products in healthcare get framed around compliance teams, enterprise workflows, or procurement-heavy platforms.

But there’s also a very practical developer problem here:

“How do I safely use clinical text in my app without passing raw identifiers everywhere?”

That problem shows up in real products like:

AI note summarizers
chart review assistants
search/indexing systems
analytics dashboards
coding assistance tools
triage automation
data labeling pipelines
internal QA or demo environments

If you are prototyping or shipping tools in this space, de-identification is not a “nice to have” step. It is foundational.

Why a clinical note de-identification API matters

Healthcare AI developers need a practical way to remove protected health information from raw note text before it reaches downstream systems. A clinical note de-identification API helps teams reduce unnecessary exposure of names, dates, identifiers, phone numbers, and locations while preserving the medical context needed for summarization, classification, search, and analytics.

That makes this kind of API useful for teams searching for:

clinical note de-identification API
PHI redaction API
healthcare text anonymization API
de-identification before LLM processing
clinical note privacy tooling

Common use cases

Here are a few places an API like this fits naturally:

1. Before sending notes to an LLM

If you are using AI to summarize, classify, or transform note content, de-identifying first adds a cleaner privacy boundary in your pipeline.

2. Before indexing notes for search

Search systems do not need a patient’s name or phone number to understand medical context.

3. For analytics and reporting

Teams often want trends and patterns, not direct identifiers.

4. For staging, testing, and demos

Demo data often starts as “temporarily sanitized later.” That is risky. A de-identifier makes this step repeatable.

5. For partner-facing integrations

When data is moving between systems, every unnecessary identifier increases exposure.

Why use an API instead of writing regex everywhere?

Because regex-only approaches usually start simple and turn messy fast.

Clinical notes are unstructured. Real-world text is inconsistent. Formats vary across systems, writers, and facilities.

Hand-rolled redaction logic often becomes:

brittle
hard to maintain
difficult to audit
inconsistent across note types

An API gives you a cleaner interface for plugging de-identification into your workflow without rebuilding the same logic in every service.

Developer-first API design

I wanted this to feel useful for developers, not just procurement decks.

That means:

straightforward API usage
easy integration into preprocessing pipelines
usable for prototypes and production-minded systems
focused on practical text redaction workflows

The ideal flow looks like this:

Clinical Note --> De-identifier API --> Safe downstream processing

Instead of:

Clinical Note --> hope everyone handles PHI carefully --> problems later

Where to find the Clinical Note De-identifier API

You can access the public RapidAPI listing here:

RapidAPI listing: Clinical Note De-identifier on RapidAPI

That gives developers a simple entry point to explore the API as a marketplace product instead of treating it like a private internal service. For an API like this, that matters: discoverability, onboarding, and fast evaluation are part of the product experience.

Example workflow

A basic architecture might look like this:

Receive raw note text
Send it to the de-identifier
Store or forward only the redacted version
Use that output for:
- summarization
- classification
- search
- analytics
- review workflows

Pseudo-example:

const response = await fetch("YOUR_API_ENDPOINT", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    "x-api-key": process.env.API_KEY
  },
  body: JSON.stringify({
    text: rawClinicalNote
  })
});

const result = await response.json();

console.log(result.redacted_text);

That simple preprocessing step can make the rest of your pipeline much safer and cleaner.

A note on trust

Healthcare data requires care.

This API is meant to help reduce exposure of sensitive information in developer workflows, but it should be used as part of a broader privacy and security approach, not as a magic checkbox.

Good engineering here means:

minimizing where raw notes travel
redacting early
logging carefully
validating outputs
applying appropriate legal, security, and compliance review for your use case

In other words: de-identification should be a core layer in the pipeline, not an afterthought.

Why I built it

I like APIs that solve a concrete bottleneck.

Clinical text is valuable. But the moment raw identifiers are mixed into everything, teams slow down, risk goes up, and every downstream integration becomes harder.

I built Clinical Note De-identifier to make that first step easier:

take raw clinical notes in, produce cleaner text out, and make the rest of the workflow more usable.

Final thoughts on privacy-first clinical note processing

If you’re building in healthtech, there’s a good chance your real product is not “redaction.”

Your product might be:

an AI assistant
a search tool
an internal dashboard
an automation workflow
an analytics platform

But de-identification is often the layer that makes those products safer to build.

That is where this API fits.

If you’re working on privacy-aware healthcare workflows and want a simpler way to preprocess note text, check out Clinical Note De-identifier on RapidAPI.

Forem: Blue Hills

Auth regression tests for CI: what to assert and why

Pattern 1: Wrong audience

Pattern 2: Expired token

Pattern 3: alg=none

Pattern 4: Algorithm confusion (RS256 → HS256)

Pattern 5: Wrong issuer

Pattern 6: Missing required claim

Pattern 7: Forged signature

Pattern 8: JWKS rotation drift

Wiring it into CI

What makes this different from a smoke test

JWT verification in production: an 8-check field guide

1. Signature

2. Issuer (iss)

3. Audience (aud)

4. Algorithm allowlist (alg)

5. Time (exp, nbf, iat)

6. Required claims

7. JWKS reachability

8. OIDC discovery integrity

What this looks like in production

Skip-the-implementation option

We rotated our JWKS without overlap. Here is the 4-minute window that broke prod.

The mechanic

The reproduction

What we actually did

What we learned

Three JWT bugs that ship to prod silently — and the 5-line CI test that catches them

Bug 1: JWKS rotation without overlap

Bug 2: Wrong audience claim

Bug 3: Issuer config drift (the OIDC discovery doc lies)

The fix: five lines of CI

Try it

Stop Sending Raw Clinical Notes to Your AI Stack

Clinical Note De-identifier API: De-Identify Clinical Notes Before AI Processing

A privacy-first API for healthcare developers building LLM, analytics, and search workflows

What the Clinical Note De-identifier API does

Why this matters for healthcare developers

Why a clinical note de-identification API matters

Common use cases

1. Before sending notes to an LLM

2. Before indexing notes for search

3. For analytics and reporting

4. For staging, testing, and demos

5. For partner-facing integrations

Why use an API instead of writing regex everywhere?

Developer-first API design

Where to find the Clinical Note De-identifier API

Example workflow

A note on trust

Why I built it

Final thoughts on privacy-first clinical note processing

Pattern 3: `alg=none`

2. Issuer (`iss`)

3. Audience (`aud`)

4. Algorithm allowlist (`alg`)

5. Time (`exp`, `nbf`, `iat`)