Multi-tenant & relay_user_id

Les deux relais reposent sur un même modèle multi-tenant. Comprenez-le ici une fois ; il s’applique de manière identique à l’Auth Relay et au Chat Relay.

Qu’est-ce qu’un tenant ?

Un tenant est une application ou un backend qui consomme un relais. Quand vous intégrez un relais, votre service devient un tenant : vous recevez une identité et des secrets, et tous vos appels sont attribués à votre tenant.

Les deux relais partagent une collection tenants commune : mêmes champs d’identité, même cycle de vie, mêmes conventions de credentials. C’est ce qui permet d’apprendre l’intégration une seule fois.

Credentials d’un tenant

Le provisioning d’un tenant renvoie, une seule fois, ses secrets :

Credential	Rôle	Relais
tenant_id	Identifiant public du tenant (en-tête de chaque appel signé).	Auth + Chat
tenant_secret	Secret de signature HMAC (à ne jamais exposer côté client).	Auth + Chat
widget_public_key	Clé publique du widget web, exposable côté navigateur.	Chat uniquement

Les secrets ne sont affichés qu'une fois

tenant_secret (et widget_public_key pour le Chat Relay) n’est retourné qu’au moment du provisioning. Stockez-le immédiatement dans un coffre à secrets. En cas de perte, faites-le tourner — voir Cycle de vie d’un tenant.

relay_user_id — le validateur universel

Un relais ne stocke pas vos mots de passe et ne « possède » pas vos utilisateurs. À la place, il relie votre identifiant utilisateur (backend_user_id) à une identité côté relais. Cette liaison est le relay_user_id : le validateur universel qui suit le modèle « Stripe Connect ».

1. Votre backend présente un de ses utilisateurs au relais (lors d’un appairage côté Auth Relay, ou d’un provisioning d’opérateur côté Chat Relay).
2. Le relais établit une liaison stable entre votre backend_user_id et son identité interne.
3. Les opérations suivantes (push d’approbation, élévation sudo, jeton d’opérateur…) ciblent cette liaison, jamais un compte global partagé.

Un même utilisateur réel peut ainsi être lié à plusieurs tenants et plusieurs backends à la fois, chaque liaison restant cloisonnée.

Isolation entre locataires

Le cloisonnement est une garantie de premier ordre :

• Chat Relay — un jeton d’opérateur est délivré avec une portée tids: { tenant_id: rôle } limitée au tenant appelant. Le tenant A ne peut pas forger un jeton ouvrant la boîte de réception du tenant B.
• Auth Relay — les appairages et les défis sont rattachés au tenant qui les a créés ; un tenant ne voit jamais les appareils d’un autre.

Comme l’appelant est déjà authentifié par HMAC, le relais connaît son tenant_id de façon fiable avant d’appliquer cette portée.

Note

Les listes de ciblage (par exemple relay_user_linked_id_list et relay_group_linked_id_list pour l’élévation sudo de l’Auth Relay) référencent ces liaisons par tenant. Voir Sudo (élévation).

Étapes suivantes

• Authentification (HMAC) — signer vos appels.
• Cycle de vie d’un tenant — provisionner et faire tourner les secrets.