Harden OAuth client and token validation

[haradahinata]

Summary

Fixes three related OAuth security issues:

• Fixes Security: OAuth redirect_uri not validated #6 by validating redirect_uri against the registered OAuth client redirect URIs on /authorize, /login, and /callback.
• Fixes Security: Access tokens never expire #7 by issuing OAuth access tokens with a 90-day expiresAt, returning expires_in, and rejecting/removing expired OAuth tokens during resolveUser.
• Fixes Security: Client secret comparison not timing-safe #8 by replacing direct client-secret comparison with a fixed-length SHA-256 digest comparison using crypto.timingSafeEqual.

Notes

The redirect URI helper accepts the current expected redirectUris array and also supports a legacy single redirectUri string if any existing client documents use that shape.

For existing OAuth tokens without expiresAt, validation falls back to createdAt + 90 days; tokens without either timestamp are rejected.

Validation

• npm ci in functions/
• npm run build in functions/
• git diff --check

I saw the earlier discussion about treating these as S-size security fixes under BOUNTIES.md. If you are open to formalizing the three related fixes together, I would be happy to coordinate the payout process you prefer after review.

[nick-transition]

Thank you @haradahinata — this is a careful, well-built fix, and I appreciate you tackling all three issues coherently instead of piecemeal.

Review notes against #6/#7/#8:

• redirect_uri validation (#6) — covered on all three flows (/authorize, /login, /callback), plus the URL parse sanity check. I verified the production client documents use the redirectUris array shape, so this lands cleanly with no migration needed.
• Token expiry (#7) — the fail-closed fallback (tokens with neither expiresAt nor createdAt are rejected) is the right call for a security fix; worst case is a forced re-auth.
• Timing-safe comparison (#8) — hashing both sides to fixed-length digests before timingSafeEqual avoids even the length-leak of the usual length-guard pattern. Nice touch.

Also verified locally: merged against current main, npm ci && npm run build clean in functions/, and the extraction into oauthSecurity.ts leaves the handlers easy to read and the logic unit-testable.

On the bounty note: as you said, these weren't formalized live bounties, so there's no committed dollar amount attached — but this merge earns PR points toward the monthly contributor pool per CONTRIBUTING.md (sizing this as M). Thanks again for the quality work here.