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, les clients sont publics (pas de secret) et l’enregistrement est dynamique — aucune revue d’application manuelle :
| É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. Demandez une scope plus étroite (codes de permission séparés par des espaces, p. ex. customers_view job_requests_view) pour limiter l’accès ; omettez-la pour un accès complet à l’entreprise. 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.