Construire une intégration multi-locataire avec OAuth 2.1
Laissez vos utilisateurs connecter leur propre entreprise Crisphive à votre produit — OAuth 2.1 avec écran de consentement, sans jamais copier de clé API.
Les clés API authentifient votre propre entreprise. Quand vous construisez un produit auquel d’autres entreprises Crisphive se branchent — une synchronisation CRM, un widget de réservation, un connecteur d’agent IA — utilisez plutôt le serveur d’autorisation OAuth 2.1 intégré : chaque propriétaire approuve votre application sur un écran de consentement, et votre application reçoit des jetons liés à son locataire.
/v1 et le point de terminaison /mcp. Envoyez Authorization: Bearer <access_token> exactement comme une clé API.Le flux
Le serveur implémente la version actuelle d’OAuth 2.1 : PKCE (S256) est obligatoire et l’enregistrement est dynamique — aucune revue d’application manuelle. Les clients auto-enregistrés sont publics (pas de secret) ; les plateformes partenaires comme Zapier et Make utilisent un client id et un secret émis par Crisphive, et seules celles-ci apparaissent comme Verified sur l’écran de consentement :
| Étape | Requête |
|---|---|
| 1. Découvrir l’AS | GET /.well-known/oauth-authorization-server (RFC 8414) → URL des endpoints, grants pris en charge |
| 2. S’enregistrer | POST /oauth/register (RFC 7591 Dynamic Client Registration) → client_id |
| 3. Autoriser | GET /oauth/authorize?… — le propriétaire se connecte à Crisphive et consent |
| 4. Échanger | POST /oauth/token (grant_type=authorization_code, code, code_verifier) → { access_token, refresh_token, expires_in } |
| 5. Rafraîchir | POST /oauth/token (grant_type=refresh_token) → une paire de jetons rotée (l’ancien refresh token est à usage unique) |
Jetons
Le jeton est lié à l’entreprise, la région et l’environnement du propriétaire consentant — il ne peut jamais atteindre un autre locataire ni basculer live↔sandbox. Le jeton agit au nom de la personne qui l’a approuvé : chaque appel est vérifié par rapport au rôle actuel de ce membre, si bien que l’application ne peut jamais faire plus que ce qu’il pourrait faire dans le tableau de bord, et elle cesse de fonctionner s’il est retiré ou suspendu. Demandez une scope plus étroite (codes de permission séparés par des espaces, p. ex. customers_view job_view) pour la limiter davantage ; l’omettre signifie tout ce que ce membre peut faire. Une scope que le membre ne détient pas est refusée au moment du consentement. Les jetons d’accès vivent environ 1 heure ; rafraîchissez avec le refresh token à usage unique pour rester connecté.
Durée de vie de la connexion
Une connexion est régie par deux horloges indépendantes. Une intégration utilisée quotidiennement n’est jamais déconnectée à date fixe ; une intégration oubliée expire d’elle-même.
- Fenêtre d’inactivité — 30 jours. Chaque rafraîchissement de jeton émet un nouveau refresh token valable 30 jours de plus. Continuez à utiliser la connexion et elle se prolonge indéfiniment ; restez silencieux 30 jours et elle expire.
- Plafond absolu — 90 jours. Quelle que soit l’activité, une connexion prend fin 90 jours après son approbation par le propriétaire de l’entreprise. L’entreprise peut régler cette valeur de 1 à 365 jours par connexion sous Developers → MCP connections ; le compte à rebours est mesuré depuis l’approbation d’origine, pas depuis la modification.
Quand l’une ou l’autre horloge arrive à zéro, le rafraîchissement échoue (OAUTH_GRANT_EXPIRED) et le propriétaire doit approuver à nouveau l’application depuis l’écran de consentement. Traitez tout rafraîchissement échoué comme « relancer le flux d’autorisation », jamais comme une erreur réessayable. Les Propriétaires et Administrateurs de l’entreprise reçoivent un e-mail 14 jours avant l’expiration d’une connexion — la réapprobation exige le propriétaire dans un navigateur, c’est pourquoi l’avertissement arrive plus tôt que pour les clés.
Appeler l’API
curl "https://api.crisphive.com/v1/customers" \ -H "Authorization: Bearer <access_token>"
Vous construisez plutôt un connecteur d’agent IA ? Le serveur MCP utilise exactement ce flux — les clients MCP conformes l’exécutent automatiquement, vous n’écrivez normalement aucun code OAuth.