Agir au nom de l'utilisateur de votre site

Comment ça marche

1. Avant chaque message, le chatbot demande à votre page le token de l'utilisateur connecté (getSubjectToken) et l'envoie à Squadico.
2. Squadico échange ce token auprès de votre serveur d'autorisation contre un nouveau token : même utilisateur, destiné uniquement au connecteur. C'est le standard OAuth 2.0 Token Exchange (RFC 8693), ou le flux « on-behalf-of » (RFC 7523) pour Microsoft Entra ID.
3. Squadico appelle le connecteur avec ce nouveau token. Le token de votre site n'est jamais transmis au connecteur, ni conservé.
4. Le connecteur vérifie le token et appelle votre API au nom de l'utilisateur, idéalement par son propre échange de token.

Ce qu'il vous faut

• Un serveur d'autorisation OAuth qui sait échanger des tokens (RFC 8693) ou faire du « on-behalf-of ».
• Une application Squadico avec la vérification d'identité activée : le token n'est accepté que pour un visiteur dont votre serveur a signé l'identité (digest).
• Un connecteur MCP qui accepte des tokens émis par ce serveur d'autorisation.

1. Dans votre fournisseur d'identité

Trois éléments, quel que soit le fournisseur : un client confidentiel pour Squadico autorisé à échanger des tokens ; un destinataire (audience) qui représente le connecteur ; et, selon les fournisseurs, le client Squadico dans l'audience des tokens de votre site.

2. Dans Squadico

1. Paramètres → votre organisation → Outils → le connecteur → Configurer OAuth : URL d'autorisation et de token de votre serveur d'autorisation (si elles n'ont pas été découvertes), identifiant et secret du client Squadico.
2. Ajoutez l'URL de rappel Squadico aux URL de redirection du client : elle sert à l'autorisation de l'organisation.
3. Autorisez le connecteur une fois au nom de l'organisation : ce jeton sert uniquement à lire la liste des outils, jamais à les appeler.
4. Identité utilisée pour les appels → « L'utilisateur du site qui héberge le chatbot », puis réglez l'échange (voir le tableau).

Les réglages d'échange

3. Sur votre site

Activez la vérification d'identité de l'application, calculez le digest de l'utilisateur sur votre serveur, et donnez au chatbot une fonction qui renvoie le token courant. Elle est appelée avant chaque message : renvoyez un token à jour, ou null si personne n'est connecté.

// On your server, when the page is rendered — never in the browser
const digest = createHmac('sha256', process.env.SQUADICO_IDENTITY_SECRET)
  .update(user.id)
  .digest('hex')

// In the page
const chatbot = document.querySelector('squadico-chatbot')
chatbot.user = { id: user.id, name: user.name, digest }
// Called before every message: return the current token, refreshed if needed
chatbot.getSubjectToken = () => auth.getAccessToken()

4. Sur votre connecteur MCP

• Vérifiez la signature du token (clés publiques de votre serveur d'autorisation), son émetteur (iss) et que son audience (aud) désigne bien le connecteur.
• sub est l'utilisateur ; azp (ou appid) désigne Squadico, utile pour tracer ou restreindre ce que fait un agent.
• Pour appeler votre API, faites votre propre échange de token vers l'audience de l'API plutôt que de relayer le token reçu : la spécification MCP déconseille de relayer un token tel quel.

Tester

Obtenez un token d'un utilisateur de votre site, puis faites l'échange que fera Squadico. Le token obtenu doit contenir le même sub et l'audience du connecteur. Vous pouvez ensuite coller le token d'origine dans le champ « Token utilisateur de test » du bac à sable de votre application.

TOKEN_URL=https://<your-idp>/…/token

# The exchange Squadico makes (RFC 8693, HTTP Basic client authentication)
curl -s "$TOKEN_URL" \
  -u "<squadico-client-id>:<squadico-client-secret>" \
  -d grant_type=urn:ietf:params:oauth:grant-type:token-exchange \
  -d subject_token="$USER_TOKEN" \
  -d subject_token_type=urn:ietf:params:oauth:token-type:access_token \
  -d audience=<connector-audience> \
  -d resource=<connector-url>

# Expect a token with the same "sub" and the connector in "aud"

Dépannage