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.