फ़ेडरेशन · SSO

One tap into Busymate DevTools

आपके उपयोगकर्ता ख़ुद की पहचान से साइन-इन होकर आते हैं — न पेयरिंग, न कॉपी किए टोकन।

A partner app with an "Open in Busymate" button arcs one single-tap arrow into the Busymate dashboard where the same user appears already signed in over live request rows; below, a broker node stamps the handoff with a 60-second timer and single-use ticket, while a faint path into an admin door is blocked. partner-app Open in Busymate one tap dash.busymate.dev 200 201 broker 60s single-use admin

प्लेटफ़ॉर्म और एजेंसियों के लिए

One tap for them, one action for you

अपने उपयोगकर्ता आधार वाले पार्टनर्स के लिए टेकओवर-सेफ़ रास्ता — एक एडमिन कार्रवाई, शून्य टोकन विनिमय।

उनके लिए एक टैप

आपका यूज़र आपके प्रोडक्ट में एक बटन दबाता है और डैशबोर्ड में पहले से साइन-इन पहुँचता है। न ऑनबोर्डिंग फ़्लो, न संभालने लायक क्रेडेंशियल, न सपोर्ट डॉक्स में समझाने लायक कुछ।

आपके लिए एक एडमिन एक्शन

एक फ़ेडरेशन क्लाइंट रजिस्टर करना ही पूरा इंटीग्रेशन है। प्रति-पार्टनर कोड लिखने, होस्ट या मेंटेन करने की ज़रूरत नहीं — आपकी तरफ़ सब ज्यों का त्यों रहता है।

आपका बैकएंड, आपके तरीके से

Directus सेशन, HMAC-साइन्ड कस्टम बैकएंड या पहले से अपना Supabase प्रोजेक्ट चला रहे ऐप्स के साथ काम करता है। ब्रोकर आपकी ऑथ के अनुसार ढलता है — उलटा नहीं।

डिज़ाइन से ही टेकओवर-सुरक्षित

पहचान प्रोवाइडर और सब्जेक्ट पर कुंजीबद्ध है — कभी सिर्फ़ ईमेल पर नहीं। मौजूदा अकाउंट में मर्ज के लिए चार सख़्त गार्ड पार करने होते हैं, और एडमिन में मर्ज सीधे-सीधे नामुमकिन है।

डिफ़ॉल्ट से नियंत्रित

हर प्रोविज़न हुआ यूज़र सीमित रोल में आता है, हर क्लाइंट की अपनी रेट लिमिट है, और कुछ भी गड़बड़ दिखे तो तुरंत किल स्विच है। यूज़रों के लिए उदार, विशेषाधिकारों में कंजूस।

The handoff protocol

How one tap actually works

A short-lived, single-use code with proof-of-possession — the same shape as OAuth PKCE, minus any token in your hands.

  1. Register one client

    01

    An admin registers your federation client: the verify mode, a redirect allowlist, per-client rate limits, and the capped role every signed-in user receives.

  2. Your backend vouches

    02

    Your 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.

  3. A 60-second code

    03

    The 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.

  4. We mint the session

    04

    The 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.

The trust model

Who can see whose traffic

Defaults enforced by row-level security in the database — and the one explicit action that changes each of them.

Federation trust model: defaults and how they change
QuestionThe defaultWhat 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.

In practice

Three real setups

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 questions

क्या मेरे यूज़रों को अलग 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.

Become a partner

एक क्लाइंट रजिस्टर करें। उपयोगकर्ताओं को असली खाता और सीमित रोल मिलता है — आपका ऐप कभी टोकन नहीं छूता।

Ask your mate