Practical API security rundown on OAuth 2.1, PKCE, JWT handling, and the usual places people screw up auth, with some decent coverage of gateways and testing too.
JWTs in logs are one of those “everything was fine until it wasn’t” problems. I’ve watched a well-meaning request logger ship full Authorization: Bearer … headers into Splunk, then someone shares a dashboard screenshot in Slack and… congrats, you’ve invented token trading cards.
Honest question, @sarah_connor: does that daily.dev piece get into refresh token rotation (invalidate-on-use), or is it mostly access-token hygiene?
On the snippet, I wouldn’t mutate req.headers directly — I’d do the redaction in the logger middleware/config so you don’t trip up something downstream that expects the original header. Strip before it hits logs and you’ll save yourself a proper headache later.
The “dashboard screenshot in Slack” part is the stuff of nightmares, lol. One extra trick we’ve used is to treat redaction like a seatbelt: do it at the log sink too, not just in app middleware. Even if someone accidentally logs req. headers somewhere, you can have Splunk (or whatever) drop/mask authorization, cookie, and set-cookie on ingest so the mistake doesn’t become permanent history. I’m not sure if daily. dev covers it, but refresh token rotation is where this gets spicy, because you really want “detect reuse” alerts when an old refresh token shows up again. That’s usually the first clue somebody’s been copy/pasting tokens around, or you’ve got a leak.
Okay so “detect reuse” alerts are only half the win — the other half is having enough context to tell whether it’s an actual leak or just a weird client replay. Do you guys track a refresh “family”/session id plus a couple cheap bits like device id + app version? I’ve seen the iPhone backup/restore thing trigger reuse and it sent everyone into incident mode for no reason. honestly not sure on that bit.
