How Frost works
Signing in
Frost never sees your password. Sign-in happens on the AWS access portal itself, through the OAuth device authorization flow — Frost only holds the token that comes back.
What happens during sign-in
Frost asks AWS to start a device authorization, then opens the
verification URL AWS returns. That page is the AWS access portal — the
same one you would reach by running aws sso login. You
authenticate there, against your own identity provider if your
organisation federates Identity Center, and approve the request.
While you do that, Frost polls AWS at the interval it was given. When the approval lands, the poll returns an access token and the run continues to the profiles step. Frost never sees your credentials — only the token AWS issues at the end.
AWS asks you to close the sign-in window once you have approved. Go ahead — Frost collects the token on the poll that follows, and only treats a closed window as a cancellation if no token was waiting.
Automatic approval
The approval itself is more than one step. The verification page first asks you to confirm the request, then — once your identity provider has signed you in — asks you to grant access, and only then is the token Frost is waiting for issued. Neither step asks for anything you have to supply: they are two buttons on two pages that say what they are about to do.
So Frost clicks them. The login page is loaded in a window that stays off screen, a script Frost injects clicks through the approval steps as they appear, and if your identity provider session is still live the whole refresh finishes without anything appearing at all — no window, no browser tab, no Dock icon.
The window comes up the moment the page needs you: a password or one-time code to type, a security key to touch, a passkey to pick. It also comes up if anything is off the script — a page Frost cannot read, a button AWS has renamed, a load that fails, or a flow that simply stops making progress — so a sign-in never sits invisibly waiting for someone. In default-browser mode the same moment opens your browser instead, which is where your passkeys and saved passwords live.
Frost only ever clicks on the AWS access portal's own approval pages, never on your identity provider's, and only controls it recognises — by AWS's own id, or by an exact label such as Confirm and continue or Allow access. A control that reads like a refusal is never clicked, whatever else about it matches. Anything unrecognised is left alone for you to answer.
Which surface that is follows your settings. In the default mode the window simply appears; in Notification + hotkey mode nothing appears unannounced — Frost posts a notification saying the sign-in needs you, and opens the page when you press the hotkey or click it. Either way the interruption arrives only for the refresh that could not finish on its own.
Turn it off with Approve automatically on the Behavior page and every sign-in shows its window from the start, as it did before. Behavior settings →
Where the login page opens
The Login Page setting on the Behavior page picks between two modes.
In-app window (default)
The access portal opens in a small Frost window. Frost stays in front, the window closes itself when the run ends, and Frost can tell whether you closed it — so cancelling a sign-in aborts the run immediately instead of leaving it polling until the device code expires.
What this window cannot do is reach your browser's saved passwords or the passkeys stored in your browser profile. Hardware security keys work; platform passkeys and password managers that live in the browser do not.
It keeps its own cookies and local storage between sign-ins, separate from your browser's. That is usually what you want — a federated identity provider session carries you through a refresh without asking anything — but it also means the window stays signed in as whoever last used it. Clear Cookies on the Behavior page throws that state away, for switching identities or for a login page that has wedged itself. Behavior settings →
Default browser
Frost hands the verification URL to your default browser instead. Passkeys, password managers and browser extensions all work, and you get your identity provider's session if you are already signed in there.
The trade-off is that Frost has no window to watch: it keeps polling until you approve or until the device code expires, so abandoning a sign-in leaves the run waiting rather than failing fast. The tab is opened only when someone is at the machine to use it — a refresh that comes due while you are away holds the sign-in silently and opens the tab when you are back, so tabs never collect overnight however many times Frost tries.
Security keys and passkeys
Electron — the framework Frost's login window is built on — services WebAuthn requests but draws no interface for them. A page waiting for you to touch a YubiKey would simply sit there, with nothing on screen to say what it was waiting for. Frost fills that gap itself.
- A notice inside the window. For as long as a credential request is pending, a small toast appears at the bottom of the login window — "Touch your security key", "Confirm with your passkey", and so on — and disappears the moment the request completes or is cancelled. If the wait drags on, the notice suggests what to try.
- Attention when you have tabbed away. The Dock icon bounces (or the taskbar entry flashes) and the window title says what is pending, so a key waiting for a touch cannot go unnoticed while you are in another app.
- An account picker. If your key holds several credentials for the same identity provider, Frost asks which one to sign in with. Without that prompt the sign-in would be cancelled outright.
This applies to the in-app window only. In default-browser mode your browser provides its own prompts, so Frost stays out of the way.
The notice is drawn by a small script injected into the sign-in page, which reports back to Frost over the page's console. Nothing security relevant depends on that channel — at most, a hostile page could make Frost's Dock icon bounce.
Timeouts and cancellation
| What you do | What Frost does |
|---|---|
| Approve the sign-in | Collects the token on the next poll and continues the run |
| Close the login window | Aborts the run at once and records "Login window closed" |
| Ignore it (in-app window) | Polls until AWS expires the device code, then records "Login timed out" |
| Ignore it (default browser) | The same — Frost has no window to watch, so it polls the code out |
| Ignore the notification (notify mode) | Waits for the hotkey or a click until the device code expires, then records "Timed out waiting for user to trigger auth" |
| Walk away before it comes due | Runs the refresh anyway, but silently: if the page turns out to need you, Frost holds it — hidden, still being driven — and shows it when you are back |
| Refuse the sign-in at your identity provider | Ends the run as soon as AWS reports it, rather than polling on |
In every case the failure is recorded on the Activity page. What happens next depends on who ended it. A sign-in nobody completed is replaced straight away — no pause, no backoff — so there is always a live device code where the last one died, and a refresh that came due in the night is a login page waiting for you rather than a dead one. The tray menu says Sign-in needed — waiting for you while Frost is holding one.
Closing the login window or refusing the sign-in at your identity provider is different: that is you saying "not now", so Frost stops, quietly, and the next attempt is the one you start from the tray, the Credentials page or the hotkey.
The OAuth client registration
Frost registers itself with AWS as a public OIDC client the first time it signs you in, and stores the resulting client id and secret alongside the token. The registration is reused for later sign-ins and re-registered when it expires. If AWS ever rejects it as invalid, Frost discards the registration so the next run starts with a fresh one.
Everything stored for this lives in Frost's own configuration file, which is written with owner-only permissions — see security & privacy.