fix(auth): api credentials survived revocation and creator removal

[roncodes]

Summary

Three defects on the API credential authentication path in AuthenticateOnceWithBasicAuth / Auth::setSession() / Expirable. Each one leaves a credential live that an operator has good reason to believe is dead. Taken together, a stock Fleetbase console has no working way to revoke an API credential: Delete doesn't revoke, and "expire immediately" doesn't expire.

Reported by a downstream deployment against 1.6.35; every reference below re-verified against main (1.6.59). Private tracker: FliitAU/fliit-extension#2212.

---

1. Soft-deleted credentials still authenticate

AuthenticateOnceWithBasicAuth.php:63-66 looks the credential up with withoutGlobalScopes(), which strips both of ApiCredential's global scopes — SoftDeletingScope (from the base Fleetbase\Models\Model) and ExpiryScope (from Expirable). Expiry is then re-applied in PHP at :94 via hasExpired(). Soft-deletion never was.

So a credential the console reports as Deleted keeps authenticating indefinitely, while the console hides the row from the UI. Delete is the only revocation most operators ever perform.

This is not theoretical: a downstream production database held a credential soft-deleted on 2026-06-12 with expires_at null, still authenticating 48 days later on stock behaviour. It was created, deleted as a mistake, and recreated under the same name — and credential names are not unique, so the console list gave the operator no way to tell the two rows apart.

Fix: reject trashed() credentials with the generic not valid 401, placed before the OPTIONS shortcut so a revoked key cannot seed api key session context on a preflight either. The message is deliberately not distinct from "no such key" so a caller cannot probe for revoked-but-real keys.

2. Authentication is fail-open when the creating user is gone

Auth::setSession() at src/Support/Auth.php:63-78. An API credential carries no identity of its own — it acts as the user that created it. When User::find() no longer resolves that user (deleted, or soft-deleted on off-boarding), the if ($user) guard is skipped so is_admin is never set — but setSession() still returns true.

Authorization degrades safely: a null user fails every group and admin check. Authentication does not. The key keeps working on every read endpoint and every ungated write. Off-boarding a person therefore does not revoke the authority of the keys they created.

Fix: setSession() returns false when the credential's user does not resolve, and the middleware answers a clean 401 — the same shape an expired credential gets. The session is no longer half-populated on the way out, and trackLastUsed() is not called for a rejected request.

Worth noting for review: User declares protected $connection = 'mysql' (src/Models/User.php:76), and sandbox:sync mirrors mysql → sandbox, so production is authoritative for users. Sandbox credentials therefore resolve their creator against the same authoritative store and are unaffected. tests/Unit/Http/MiddlewareContractsTest.php previously seeded sandbox-user-1 only on the sandbox connection, which did not reflect that; the fixture now mirrors it to mysql as the real system does, and the sandbox secret-key test still passes.

3. "Expire immediately" does not expire the credential

ApiCredential::setExpiresAtAttribute() maps the console's 'immediately' option to Carbon::now() (src/Models/ApiCredential.php:144), but Expirable::hasExpired() used a strict < (src/Traits/Expirable.php:91) — now() < now() is false.

ExpiryScope already disagreed with it: it keeps a row only while expires_at > now() (src/Scopes/ExpiryScope.php:26), i.e. it treats an exactly-now expiry as expired. The trait and the scope were on opposite sides of the same boundary.

Fix: hasExpired() is now inclusive (<=), which makes the two agree and makes "expire this key right now" actually take effect.

---

Not addressed here

• Per-key roles / scopes. A credential still has no scope of its own — Auth::setSession() derives is_admin from whoever clicked "Create", so every key an admin creates is a full-admin key regardless of its name. Least privilege is only reachable indirectly, by scoping the creator into a dedicated service user. ApiCredential already uses HasPolicies and HasPermissions, so the plumbing partly exists but nothing on the auth path consults it. That's a feature, not a fix, and wants a design discussion — happy to open a separate issue.
• Console expiry dropdown serializes every option to null. That one is in dev-engine (api-credential.js declares @attr('date') expires_at while the form assigns relative strings), not this repo.

Testing

php vendor/bin/pest — 1422 passed, 0 failed (9966 assertions). php-cs-fixer clean.

New coverage:

• revoked credential rejected on a normal request, with no session context and no last_used_at write
• revoked credential rejected on an OPTIONS preflight
• credential whose creator has been soft-deleted rejected, with no session context and no last_used_at write
• Auth::setSession() returns false for an orphaned credential (unit level, AuthSupportTest)
• hasExpired() is true at an exactly-now expiry (LifecycleTraitsTest)

Compatibility

Auth::setSession() can now return false for an ApiCredential whose user is gone. The only in-tree caller that passes an ApiCredential is this middleware; the User branch is untouched. Any deployment currently relying on credentials outliving their creator will see those keys start returning 401 — which is the intent.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (6317e91) to head (f62f093).
⚠️ Report is 1 commits behind head on dev-v1.6.60.

Additional details and impacted files

@@               Coverage Diff               @@
##             dev-v1.6.60      #246   +/-   ##
===============================================
  Coverage         100.00%   100.00%           
- Complexity          6730      6732    +2     
===============================================
  Files                397       397           
  Lines              22448     22455    +7     
===============================================
+ Hits               22448     22455    +7     

Flag	Coverage Δ
backend	100.00% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.