Designing a Seamless, Secure CLI/SSO Auth System for Agent Skills

Abstract

Agent‑driven Skills need to call internal business CLIs that rely on the company’s unified SSO. Traditional browser‑based SSO cannot be used because Agents have no interactive UI, leading to three progressive security gaps: missing login, missing user isolation, and plaintext token storage. A native, browser‑free, multi‑user isolated authentication framework is built around sso-cli, business CLIs, and a private sso-sdk Go package.

1. Background – Why a New Auth Scheme Is Required

Feishu open‑sourced its CLI in March 2026, popularising the concept of an Agent CLI that outputs structured data, defines unified exit codes and error semantics, and is intended for AI consumption. When these CLIs were integrated into Agent frameworks (e.g., Openclaw, Claude Code), the lack of a browser‑based SSO flow blocked authentication.

Three concrete challenges emerged after integration:

Login missing – Agents cannot trigger the interactive redirect; early practice stored long‑lived tokens in environment variables or config files, exposing them and removing per‑user identity.

Isolation missing – A shared sandbox allowed one user’s token to be reused by another, causing audit mismatches and unauthorized data access.

Storage missing – Even when login and isolation were handled, plaintext tokens remained on disk, making them trivially stealable.

These pain points demand a native, browser‑free, multi‑user isolated, leak‑proof SSO solution.

2. Overall Architecture Overview

The system consists of four components:

sso-cli : an independent command‑line binary that orchestrates the SSO login flow, encrypts credentials, and enforces per‑user isolation. It never exposes raw tokens.

Business CLI : command‑line tools built by product teams (e.g., abtest-cli, trade-cli) that the Agent invokes. They delegate token acquisition to the SDK.

sso-sdk : a private Go SDK that reads and decrypts tokens from local secure storage and provides a GetToken() API to Business CLIs.

SSO Platform : the internal unified SSO service, extended with an “Agent Poll Authorization Mode” that issues a one‑time login link and a short‑lived code for token exchange.

Typical runtime flow:

Agent decides to invoke a Business CLI.

The Business CLI calls sso-sdk to obtain the current user’s token.

If the token is missing or expired, the SDK returns an error; the Agent triggers an SSO login Skill. sso-cli requests a one‑time code from the SSO platform, generates a Feishu card containing the login link, and sends it to the user.

The user clicks the card, completes SSO login in a browser; the platform validates the code and returns a token. sso-cli encrypts the token with a master key, writes it to a local ciphertext file, deletes the card, and signals success to the Agent.

The Agent retries the Business CLI call, which now receives a valid token.

3. sso-cli – Secure Storage and Invisible Login Core

3.1 Master Key and OS Keychain

On first execution, sso-cli generates a high‑entropy master key and stores it in the native OS keychain:

macOS – Keychain

Linux – Secret Service / GNOME Keyring

Windows – Credential Manager / DPAPI

The master key is fetched only when encryption or decryption is needed and cleared from memory immediately after use, ensuring that even if the sandbox file system is readable, the key remains protected.

3.2 Encrypted File Storage

After a successful login, sso-cli serialises a user→token map, encrypts it with the master key, and writes the ciphertext to a single local file. Without the master key, the file is useless, providing confidentiality even if the entire sandbox is exfiltrated.

All users share the same encrypted file; isolation is achieved by encrypting each user’s entry with a per‑user derived key, simplifying concurrency control.

3.3 Multi‑User Isolation & Temporary Encrypted Environment Variables

Each dialogue round defines a “current user”. The Agent framework injects a set of encrypted temporary environment variables that encode the user identifier. Only components that share the derived key (the sso-sdk) can decrypt them.

Properties of these variables:

They exist only for the lifetime of the dialogue and are removed immediately after the conversation ends.

They are not written to shell history and are private to the process, so they do not appear in /proc listings.

If an attacker reads the variable values, they see only ciphertext and cannot infer or forge another user’s identity.

Concurrent operations use file locks: reads are concurrent (decryption is idempotent); writes (token refresh) acquire an exclusive lock to avoid race conditions.

3.4 Feishu Hook Login – Invisible Authorization

The initial sso-cli flow required the Agent to ask the user to open a browser, wait for a manual “I’m logged in” confirmation, and then poll – a pattern that caused time‑outs.

Hook mode replaces the manual step with a Feishu card: sso-cli intercepts its JSON output and creates a Feishu card visible only to the invoking user.

The user clicks the card and completes SSO login in a browser.

Meanwhile sso-cli polls the SSO platform at fixed intervals using the one‑time code.

When the token is obtained, sso-cli encrypts it locally, deletes the card (no trace), and returns success to the Agent.

If card capability is unavailable, sso-cli falls back to sending a plain‑text message with the one‑time link; the link remains one‑time and the token never appears in the message.

4. SSO Platform Evolution – Agent‑Friendly Poll Mode

Traditional SSO only supports real‑time web callbacks, unsuitable for asynchronous Agent scenarios. The platform was extended with an “Agent Poll Authorization Mode” that issues a one‑time login link and a short‑lived code for polling.

Agent Poll Authorization Flow:

Agent (via sso-cli) requests a one‑time login link; the platform returns the link and a bound code.

The link is presented to the authorized user through a Feishu card (or other channel).

The user opens the link, completes SSO login; the link expires immediately. sso-cli polls the token endpoint using the same code until the token is issued.

After the first successful exchange, the platform marks the code as used and enforces an absolute expiration.

The token is stored via the master‑key‑encrypted file mechanism for Business CLI consumption.

Security highlights:

One‑time link + one‑time code prevent replay.

Code expires automatically, mitigating brute‑force polling.

Polling is idempotent; subsequent attempts fail gracefully after the code is consumed.

User verification during polling ensures the authorizing user matches the requester, rejecting mismatched attempts.

5. Business CLI Integration – Secure Token Retrieval

Business CLI developers only need to import the private sso-sdk package and call its token‑fetching method.

5.1 Private Package Permission Control

The SDK is hosted on an internal Go Module Proxy with strict repository permissions. Only approved business modules can download the package; unauthorized import attempts are blocked at the proxy level, providing compile‑time access control.

5.2 Separation of Retrieval Logic and Storage

sso-cli

remains the daemon responsible for login and encrypted storage, while sso-sdk only reads and decrypts tokens. This separation reduces the error surface and eliminates inter‑process communication failures.

Runtime steps for a Business CLI call:

Read the encrypted temporary environment variable and decrypt the salt to obtain the current user identifier.

Load and decrypt the corresponding token from the local ciphertext file.

Check token expiration; if expired, return an error.

Return the valid token to the Business CLI.

The entire flow occurs locally without network or IPC, ensuring speed and security.

5.3 Further Obfuscation – Protecting Critical Logic

To raise reverse‑engineering cost, the token acquisition and decryption logic can be compiled into a separate binary object ( .so / .dylib) and loaded at runtime, or built with Go’s plugin package or CGO static linking to hide symbols. This approach makes static analysis of strings ineffective, though it adds debugging overhead.

6. Summary and Outlook

The combined solution— sso-cli secure storage , Feishu invisible login , private SDK access control , multi‑user encrypted isolation , and SSO platform poll mode —delivers:

Tokens hidden from environment variables, command lines, logs, and plaintext files.

Every operation bound to a real user, satisfying audit and least‑privilege requirements.

One‑click authorization with no extra user interaction.

Simple integration: Business CLIs only import the shared SDK.

Depth‑in‑defense layering from OS keychain, encrypted files, private repository gating, encrypted env vars, to one‑time codes.

The system is already deployed in multiple internal Agent Skills, balancing security, usability, and developer efficiency.

Future direction envisions decoupling user identity , Agent identity , and function permissions into a three‑dimensional access‑policy engine. The existing secure storage, encryption, and poll mechanisms will serve as a trusted foundation for that more complex, context‑aware authorization model.