How-To Series · Module 1: Get Running
Desktop Native Sign-In: RFC 8252
The Desktop app signs in through your real browser with PKCE, no embedded webview.
After this videoYour desktop app authenticates like a first-class native citizen
When the Hermes Desktop app connects to a gated gateway, it uses RFC 8252 native sign-in. It opens your real system browser, you approve there, and the app receives its own OAuth tokens stored in your OS keychain. No embedded webview, no session cookies. The app detects gateway capability via the auth_flows array and falls back to the legacy embedded flow automatically when native PKCE is not advertised. PKCE protects the loopback redirect, tokens rotate via refresh, and gateway operators get the native routes automatically with no configuration.
About these resources. This episode explains the native sign-in subsystem in Hermes Desktop. The Sources block names the Hermes docs page that backs every claim.
New words here · Plain English
one sentence each · full glossaryNative sign-inAn OAuth flow where a desktop app opens your real system browser to authenticate, then receives its own tokens. No embedded webview required.
PKCEProof Key for Code Exchange. A security extension that binds the authorization code to a verifier only the app knows, preventing code interception.
Loopback redirectA redirect to a local port on your own machine, used by native apps to receive the authorization code from the browser.
Keychain storageThe OS-level encrypted store where the desktop app saves its OAuth tokens, so they are protected at rest.
Sources · What this video distills
1 docs page · every concept below traces to itHow it works · The PKCE flow
the authorization sequence the app runsGET /api/status -> auth_flows: ["cookie", "native_pkce"]GET /auth/native/authorize (opens system browser with PKCE challenge)POST /auth/native/token (code + PKCE verifier -> access_token, refresh_token)POST /auth/native/refresh (refresh_token -> new access_token + refresh_token)