Eine Multi-Tenant-Integration mit OAuth 2.1 bauen
Lassen Sie Ihre Nutzer ihr eigenes Crisphive-Unternehmen mit Ihrem Produkt verbinden — OAuth 2.1 mit Consent-Screen, ohne dass je ein API-Schlüssel kopiert wird.
API-Schlüssel authentifizieren Ihr eigenes Unternehmen. Wenn Sie ein Produkt bauen, an das andere Crisphive-Unternehmen andocken — eine CRM-Synchronisation, ein Buchungs-Widget, ein KI-Agent-Connector — nutzen Sie stattdessen den eingebauten OAuth 2.1 Authorization Server: Jeder Unternehmensinhaber genehmigt Ihre App auf einem Consent-Screen, und Ihre App erhält Tokens, die an dessen Mandanten gebunden sind.
/v1 und dem /mcp-Endpunkt. Senden Sie Authorization: Bearer <access_token> genau wie einen API-Schlüssel.Der Ablauf
Der Server implementiert den aktuellen OAuth-2.1-Entwurf: PKCE (S256) ist Pflicht, Clients sind öffentlich (kein Secret), und die Registrierung ist dynamisch — kein manueller App-Review:
| Schritt | Request |
|---|---|
| 1. AS entdecken | GET /.well-known/oauth-authorization-server (RFC 8414) → Endpoint-URLs, unterstützte Grants |
| 2. Registrieren | POST /oauth/register (RFC 7591 Dynamic Client Registration) → client_id |
| 3. Autorisieren | GET /oauth/authorize?… — der Unternehmensinhaber meldet sich bei Crisphive an und stimmt zu |
| 4. Einlösen | POST /oauth/token (grant_type=authorization_code, code, code_verifier) → { access_token, refresh_token, expires_in } |
| 5. Erneuern | POST /oauth/token (grant_type=refresh_token) → ein rotiertes Token-Paar (das alte Refresh-Token ist einmalig verwendbar) |
Tokens
Das Token ist an Unternehmen, Region und Umgebung des zustimmenden Inhabers gebunden — es kann nie einen anderen Mandanten erreichen oder zwischen Live↔Sandbox wechseln. Fordern Sie einen engeren scope an (durch Leerzeichen getrennte Berechtigungscodes, z. B. customers_view job_requests_view), um den Zugriff zu begrenzen; lassen Sie ihn weg für vollen Unternehmenszugriff. Access-Tokens leben ~1 Stunde; erneuern Sie mit dem einmalig verwendbaren Refresh-Token, um verbunden zu bleiben.
Verbindungslaufzeit
Eine Verbindung wird von zwei unabhängigen Uhren bestimmt. Eine täglich genutzte Integration wird nie planmäßig getrennt; eine vergessene läuft von selbst ab.
- Inaktivitätsfenster — 30 Tage. Jede Token-Erneuerung stellt ein neues Refresh-Token aus, das weitere 30 Tage gilt. Nutzen Sie die Verbindung weiter, verlängert sie sich unbegrenzt; bleiben Sie 30 Tage inaktiv, erlischt sie.
- Absolute Obergrenze — 90 Tage. Unabhängig von der Aktivität endet eine Verbindung 90 Tage, nachdem der Unternehmensinhaber sie genehmigt hat. Das Unternehmen kann dies pro Verbindung unter Developers → MCP connections auf einen Wert von 1 bis 365 Tagen setzen; der Countdown wird ab der ursprünglichen Genehmigung gemessen, nicht ab der Änderung.
Läuft eine der beiden Uhren ab, schlägt das Erneuern fehl (OAUTH_GRANT_EXPIRED), und der Inhaber muss die App erneut über den Consent-Screen genehmigen. Behandeln Sie jede fehlgeschlagene Erneuerung als „Autorisierungsablauf neu starten“, niemals als wiederholbaren Fehler. Die Inhaber und Administratoren des Unternehmens werden 14 Tage bevor eine Verbindung abläuft per E-Mail benachrichtigt — die erneute Genehmigung erfordert den Inhaber im Browser, daher kommt die Warnung früher als bei Schlüsseln.
Die API aufrufen
curl "https://api.crisphive.com/v1/customers" \ -H "Authorization: Bearer <access_token>"
Sie bauen stattdessen einen KI-Agent-Connector? Der MCP-Server nutzt genau diesen Ablauf — konforme MCP-Clients führen ihn automatisch aus, Sie schreiben normalerweise gar keinen OAuth-Code.