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.
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. It gives up once, quietly, when the code expires — it does not open a second tab.
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 gives up |
| 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 — and then Frost waits for you. A sign-in nobody completed is not retried on a timer: the retry would open another login page with nobody there to finish it, and by morning you would have one for every few minutes you were away. The tray menu says Sign-in needed, and a notification says so once — unless you closed the window or refused the sign-in yourself, in which case you already know. 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.