One tap for them,
为拥有自己用户群的合作伙伴提供防接管的入口——一次管理操作，零令牌交换。
对他们：一次点击
你的用户在你的产品里点一个按钮，到达仪表盘时已经登录。没有引导流程，没有要管理的凭据，支持文档里也没什么可解释的。
对你：一次管理操作
注册一个联邦客户端就是全部集成。没有需要编写、托管或维护的逐合作方代码——你这边一切照旧。
你的后端，按你的方式
支持 Directus 会话、HMAC 签名的自建后端，或已经运行自己 Supabase 项目的应用。代理人适配你的认证——而不是反过来。
设计层面防接管
身份以提供方加主体为键——绝不仅凭一个邮箱。并入现有账号需通过四道严格防线，而并入管理员账号则根本不可能。
默认受控
每个自动开通的用户都落在受限角色里，每个客户端都有自己的限流，一旦发现异常还有即时断闸开关。对用户慷慨，对权限吳啌。
How one tap
A short-lived, single-use code with proof-of-possession — the same shape as OAuth PKCE, minus any token in your hands.
Register one client
01An admin registers your federation client: the verify mode, a redirect allowlist, per-client rate limits, and the capped role every signed-in user receives.
Your backend vouches
02Your button calls the broker with a PKCE challenge. The broker verifies against YOUR auth — a live Directus session check, an HMAC-signed assertion, or your own Supabase JWT.
A 60-second code
03The user gets a link carrying a single-use code that expires in 60 seconds. Only its hash is stored, and the redirect target is decided server-side, at start time.
We mint the session
04The Busymate app or dashboard redeems the code with the PKCE proof and receives a real session for a real account. Your app never sees or stores a Busymate token.
Who can see
Defaults enforced by row-level security in the database — and the one explicit action that changes each of them.
| Question | The default | What changes it |
|---|---|---|
| Who sees a device? | Its owner, plus roles holding the devices-view capability — checked by the database on every read. | An admin-created access grant scoped to one device, service group, or user — with an optional expiry. |
| Who sees captured traffic? | The account that captured it. Traffic follows its captor, not the device it came from. | Nothing implicit — a device grant does not quietly widen traffic reads. |
| What role does a federated user get? | The client's capped role — a configurable least-privilege role. The database refuses an admin role at write time. | You edit the client's capped role. Role hints inside partner assertions are ignored by design. |
| Can an assertion take over an account? | No. Identity keys on client plus subject; a colliding email gets a private no-merge address instead of the existing account. | Email linking is a per-client opt-in — and even then it refuses admin and protected accounts. |
| Where can the flow redirect? | Busymate hosts plus the client's registered allowlist — exact host match; anything else collapses to the dashboard root. | The client's redirect allowlist, editable only by an admin with a confirmed write. |
| What if a client misbehaves? | Per-client rate limits that fail closed, and denial events written to the audit trail before the response is sent. | Flip the client's kill switch — it is re-checked on every sign-in start, so it takes effect immediately. |
Three real
Delegation and handover are explicit, scoped rows — not tribal shared passwords.
“Give our contractor the three staging phones”
One access grant: a non-admin role scoped to that service group, with an expiry date. Revoking deletes the row — the contractor's reach evaluates to nothing on the very next database check.
“Hand this device to a teammate”
An admin-confirmed transfer moves ownership in one transaction. Captured history stays with whoever captured it and device-local settings are wiped — a clean handover, not a data migration.
“Let our platform's users debug from inside our product”
Each user's button-tap lands them in their own real Busymate account, homed in your client's tenant, clamped to your capped role. Your product keeps its auth; ours keeps its tokens.
Partner
我的用户需要单独的 Busymate 登录吗？
不需要——一次点击就让他们以自己的身份登录进入 Busymate DevTools，无需配对、无需复制令牌、没有第二个登录页。
集成需要写多少代码？
交接本身零代码。注册一个联邦客户端就是全部配置——没有需要编写或维护的逐合作方代码。
支持哪些身份提供方？
Directus 会话、HMAC 签名的自建后端，或已经运行自己 Supabase 项目的应用。
怎么防止恶意合作方接管现有账号？
身份以（提供方，主体）为键，除非四道严格防线全部通过，否则绝不会凭邮箱并入现有账号——也永远不会并入管理员账号。
How long does the sign-in link live, and can it be replayed?
The code in the link is single-use and expires in 60 seconds. Redeeming it requires the PKCE proof-of-possession, only its hash is ever stored, and HMAC assertions carry a single-use nonce checked atomically.
What happens when I disable a client or revoke a grant?
Disabling a client is re-checked on every sign-in start, so it bites immediately. Revoking an access grant deletes it — existing sessions keep their own expiry, but the delegated reach evaluates to nothing on the next database check.
Is there an audit trail for federated sign-ins?
Yes. Every start and exchange lands in the shared audit trail with the client, verify mode, outcome and denial reason — and denied events are written before the response goes out, so a probe can't outrun its own record.
Can a federated user ever become an admin?
No. A database trigger refuses an admin capped role on any client, the broker ignores role hints inside assertions, and email linking never merges into an admin or protected account.