One tap for them,
自前のユーザー基盤を持つパートナーに、乗っ取り安全な入口を——管理操作 1 回、トークン交換ゼロ。
ユーザーにはワンタップ
ユーザーはあなたの製品内のボタンをクリックするだけで、サインイン済みの状態でダッシュボードに到着します。オンボーディングフローも、管理すべき認証情報も、サポートドキュメントに書くこともありません。
あなたには管理操作一回
フェデレーションクライアントを一つ登録することが、統合のすべてです。パートナーごとのコードを書く・ホストする・保守する必要はなく、あなた側は何も変わりません。
あなたのバックエンドを、あなたのやり方で
Directus セッション、HMAC 署名のカスタムバックエンド、すでに自前の Supabase プロジェクトを運用中のアプリに対応。ブローカーがあなたの認証に合わせます——逆ではありません。
設計から乗っ取り対策済み
ID はプロバイダーとサブジェクトの組でキー付けされ——メールアドレス単体では決して紐付けません。既存アカウントへのマージには四つの厳格なガードの通過が必要で、管理者アカウントへのマージはそもそも不可能です。
デフォルトで封じ込め
プロビジョニングされたユーザーは必ず上限付きロールに入り、クライアントごとにレート制限があり、異変があれば即座にキルスイッチを切れます。ユーザーには寛大に、権限には厳格に。
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 に入ります。ペアリングなし、トークンのコピーなし、二つ目のログイン画面なし。
統合にどれくらいコードを書く必要がありますか？
ハンドオフ自体にはゼロ。フェデレーションクライアントを一つ登録するのがセットアップのすべてで、パートナーごとのコードは存在しません。
どの ID プロバイダーに対応していますか？
Directus セッション、HMAC 署名のカスタムバックエンド、すでに自前の Supabase プロジェクトを運用中のアプリです。
悪意あるパートナーによる既存アカウントの乗っ取りは何が防ぐのですか？
ID は（プロバイダー、サブジェクト）でキー付けされ、四つの厳格なガードを通過しない限りメールで既存アカウントにマージされることはなく——管理者アカウントには決してマージされません。
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.