Summary

Two related defects in the MinTokenLength enforcement chain. They were originally surfaced together by a 2-week investigation on the Evri Apigee→Tyk migration; this PR fixes both in one go because they are coupled — the create-time guard has to mirror whatever the runtime gate does, and changing only one of them just moves the trap.

1. Silent-accept on create. POST /tyk/keys/<customID> historically stored any custom-ID key regardless of length. If the key was unreachable at auth time, the operator got no signal at create — they got 200 OK, the session went into Redis, and then every consumer request 403'd with response_flag=AKI. This PR rejects the create with 400 Bad Request whenever len(customID) < MinTokenLength, with an error message that names both the submitted length and the configured minimum.
2. Off-by-one operator at the runtime gate. gateway/middleware.go::CheckSessionAndIdentityForValidKey used if len(key) <= minLength, which rejects a key whose length is exactly MinTokenLength. The config field reads as a minimum accepted length, but was enforced as a strict lower bound — which is what bit Evri (32-char Apigee keys vs MinTokenLength=32). This PR changes the gate to if len(key) < minLength, so a key of length equal to MinTokenLength is accepted, matching the field's name and documentation. The create-time guard above mirrors the same < semantic.

Background — how this was found

The Evri Apigee-to-Tyk migration PoC was blocked for ~2 weeks on 403s across every imported key. Apigee default consumer keys are 32 chars; Evri had set TYK_GW_MINTOKENLENGTH=32 thinking it was the minimum accepted length. Tyk's auth middleware used len(key) <= minLength, so 32-char keys were rejected before any Redis lookup — but the create path happily accepted and stored them. The only form that worked was the eyJ… envelope (120+ chars), which external-system consumers don't have. Two weeks of investigation chased Portal/Dashboard/REGO/hash-function code paths before the length gate surfaced.

There are two distinct mistakes made by the operator+code interaction here, and fixing only one of them leaves a real trap behind:

• If we only fix the silent-accept (1), the operator with MinTokenLength=32 still can't create a 32-char key — the field name lied to them, and they have to hunt for the off-by-one in code.
• If we only fix the operator (2), an operator with MinTokenLength=64 can still POST a 30-char custom-ID key, get 200 OK, and silently 403 every consumer request.

So both fixes ship together.

Behavior matrix (before vs after)

Reproduced on tyk-demo with min_token_length: 32:

Implementation

1. Runtime gate (gateway/middleware.go)

- if len(key) <= minLength {
+ if len(key) < minLength {
      return user.SessionState{IsInactive: true}, false
  }

Default fallback (minLength = 3 when MinTokenLength is unset) is unchanged in placement; only the comparison flips. Effect: in the default-config case, a key of length exactly 3 now authenticates instead of being rejected. There are no tests asserting the old boundary behavior.

2. Create-time guard (gateway/api.go::handleAddOrUpdate, POST branch)

minLen := gw.GetConfig().MinTokenLength
if keyName != "" && minLen > 0 && len(keyName) < minLen {
    return apiError(fmt.Sprintf(
        "custom key ID length %d is less than min_token_length (%d); "+
            "the key would be unreachable at auth time. Use an ID of at least min_token_length characters, "+
            "or lower min_token_length in the gateway configuration.",
        len(keyName), minLen,
    )), http.StatusBadRequest
}

Gated on keyName != \"\" so autogenerated creates fall through. Gated on minLen > 0 so the default-config path (where MinTokenLength is 0 / unset, and the middleware falls back to 3) is not affected by this guard — that case is handled by the runtime gate's default; this PR intentionally doesn't over-apply.

PUT/update path unchanged. Existing keys created before this fix remain returnable/mutable/deletable via the admin API — important for cleanup of pre-fix imports.

Test plan

TestKeyHandler_RejectCustomKeyBelowMinTokenLength (in gateway/api_test.go) exercises, with MinTokenLength=32:

• Custom ID strictly below MinTokenLength (len=31) → 400 (rejected)
• Custom ID exactly equal to MinTokenLength (len=32) → 200 (accepted — the case that bit Evri, now the canonical "works" case)
• Custom ID above MinTokenLength (len=34) → 200 (unchanged)
• Autogenerated create (POST /tyk/keys/create) → 200 (unchanged)
• Broader regression: TestKeyHandler|TestCreateKey|TestHashKeyHandler|TestCheckSession|TestAuthKey suite passes locally.

go test ./gateway/ -run TestKeyHandler_RejectCustomKeyBelowMinTokenLength -v -count=1
go test ./gateway/ -run 'TestKeyHandler|TestCreateKey|TestHashKeyHandler|TestCheckSession|TestAuthKey' -count=1

Backwards compatibility

Both changes are pure relaxations or loud-failure additions — no traffic that previously authenticated will stop authenticating, and no key creation that previously produced a usable key will now fail.

• Runtime gate (<= → <): keys whose raw length equals MinTokenLength go from rejected at auth time → accepted at auth time. Anyone relying on the old <= semantics intentionally (e.g., wanting "strictly greater than 32") would have configured MinTokenLength=33 to express that, so this is not a breaking change in practice. The field name and docs both read as "minimum accepted," which is now what the code does.
• Create-time guard: rejects only inputs that would have been silently broken under the old behavior. There is no input being rejected that previously produced a working key.
• Default config (MinTokenLength unset): runtime gate's default is minLength = 3. The operator change means a key of length exactly 3 now authenticates instead of being rejected. Tyk-generated tokens are always far above this; the only practical effect is that hand-typed 3-char custom IDs (uncommon — and arguably should work given the field is called "min_token_length") now work.
• Existing keys: unaffected on read / update / delete paths.

References

• TT-17065
• Customer-engineering journal (internal): `deployed-engineering/customers/evri/credentials/2026-04-24-apigee-keys-403-mintokenlength.md`
• Generalised migration pattern (internal): `deployed-engineering/use-cases/migration/apigee-to-tyk/patterns/mintokenlength-and-custom-keys.md`

Follow-up (separate ticket): add the same create-time guard to the Dashboard layer (`tyk-analytics/dashboard/api_keys.go::createKey`). Not required for correctness — the Gateway 400 here bubbles up — but it's a nicer UX for Dashboard UI/API clients to fail fast without a Gateway round-trip.

🤖 Generated with Claude Code