Internal Tooling Behind SSO

Anyone reaching one of these tools with a browser: log into any one of them, or get redirected there by any other, and the session carries across the whole internal tool set without a second login. It’s also the template for anyone adding the next internal tool — the default is "reuse the shared gate," not "decide auth from scratch."

Building or maintaining a separate login system for each small internal tool doesn’t scale for a single-operator project, and it fragments what’s functionally one trusted user base across many separate sessions. The shared pattern instead puts one login gate in front of anything with a plain human-browser audience and no login of its own. Any new internal tool inherits the existing session automatically — no per-app setup needed to add another one to the set.

This isn’t the only auth pattern in the fleet — a few apps already have real logins of their own, and internal agent-to-agent traffic bypasses it entirely, trusted by network policy rather than a login. But it is the default: whenever a new internal tool has a plain browser audience and no login of its own, this is the pattern it gets. See Authentication's full breakdown for why each app landed where it did.

The podcast pipeline (Daily News Podcast) needed an operator-facing view of its own recent activity, across all three of its shows — separate from the shows themselves, which are deliberately public with no auth at all, since podcast apps can’t complete a login. This dashboard view is the opposite case: a genuinely internal surface, meant for one operator, browser-driven — exactly what the shared gate is for. There’s also a small frontend for it, linked as a card from the main dashboard, so an operator can click through rather than hitting the raw view directly.

The shared gate’s full mechanism lives in Authentication.