Webator

The Use Case

Think about a classic PAM (Privileged Access Management) scenario: you have web-based tools like Zabbix, phpIPAM, or internal admin portals that certain people need access to, but you don't want to hand out direct credentials. Instead, a user connects via RDP to a jump server, and from there they can open the applications they're authorized to use — already logged in, no credentials visible.

That's what Webator does. It sits on the RDP server, and when a user launches an app, Webator opens a browser, handles the entire login flow automatically (including MFA), and presents the application ready to use. The user never sees or types a password. They just get access to what they're allowed to access.

Why I Built It

A lot of internal web apps don't support SSO or any kind of federated auth. They have their own login pages, sometimes with MFA, sometimes with multi-step flows like Azure AD. In a PAM setup, you need something that can automate those logins on behalf of the user without exposing the actual credentials. Most commercial PAM solutions cost a fortune and are overkill for what I needed.

Webator fills that gap. It's a single binary you drop on the jump server, configure once with a JSON file, and it handles the rest.

How It Works

Under the hood, Webator uses chromedp to drive a real Chrome or Edge browser via the DevTools Protocol. It's not a headless mock renderer — it launches an actual browser window with full JavaScript support, which means it works with any login page no matter how complex the frontend is.

You define destinations in a JSON config: the URL, the form selectors (CSS, XPath, or ID), the credentials, and optionally a TOTP secret for MFA. When launched, Webator fills the forms, clicks through the steps, waits for MFA fields to appear, generates and submits TOTP codes, detects successful login, and navigates to the target page. The browser stays open for the user to work with.

Multi-Destination Picker

On the RDP server, you typically have multiple apps a user might need. Webator supports a multi-destination config where each target has its own credentials, selectors, and settings. When the user launches Webator, a GUI picker shows the apps they can access. Pick one, and it opens — already authenticated.

There's also a tagging and filtering system so you can pre-configure which destinations are available to which users or launch specific targets via command line flags in scripts or shortcuts.

MFA / TOTP

This was the hardest part to get right. Most portals show the MFA field on a separate page after username and password — think Azure AD where you type your email, get redirected, then type your password, then get a TOTP prompt. Webator handles all of this automatically. It supports both one-step (all fields on one page) and two-step (MFA on a second page) flows, generating TOTP codes from a Base32 secret using RFC 6238.

The TOTP secrets can be stored in the config or passed via CLI flags at runtime for better security.

Display Modes

• Kiosk mode — fullscreen, no address bar, no right-click, no dev tools. Perfect for locked-down RDP sessions where users shouldn't mess with browser settings
• App mode — clean window without tabs or address bar, just the application
• Standard browser window — useful for testing and debugging
• Embedded webview — native window via Fyne with the browser embedded
• Headless — no visible window, for automated scripts

For a PAM setup, kiosk mode is the way to go. The user sees only the application, can't navigate away, can't open dev tools, and can't access the credentials that got them in.

Tech Stack

Written in Go — single binary, cross-platform, easy to deploy on jump servers. The GitHub Actions pipeline builds for macOS (ARM and Intel), Linux (x86-64 and ARM64), and Windows. It even runs the binaries through VirusTotal because browser automation tools tend to trigger antivirus heuristics, and the last thing you want on an enterprise jump server is a false positive.