Skip to main content
OAuth-Apps ermöglichen Drittanbieteranwendungen den Zugriff auf Teable im Namen von Nutzern. Dieser Leitfaden erläutert, wie Sie eine OAuth-App erstellen und konfigurieren, den OAuth-2.0-Autorisierungsablauf implementieren und Zugriffstoken für die Interaktion mit der Teable-API verwenden. Teable unterstützt drei OAuth-2.0-Autorisierungsmodi:
  • Autorisierungscode + Client Secret: Für Webanwendungen mit einem Backend-Server
  • Autorisierungscode + PKCE: Für native Apps, CLI-Tools, SPAs und andere öffentliche Clients, die ein Client Secret nicht sicher speichern können
  • Geräteautorisierungs-Grant: Für Clients, die überhaupt keine Browser-Weiterleitung empfangen können, etwa eine über SSH ausgeführte CLI, ein Container oder eine Cloud-IDE

Erstellen einer OAuth-App

  1. Gehen Sie in Ihrem Teable-Konto zu Einstellungen > OAuth-Apps.
  2. Klicken Sie auf Neue OAuth-Apps, um eine neue Anwendung zu erstellen.
  3. Füllen Sie die erforderlichen Informationen aus:
    • Name der OAuth-App: Ein aussagekräftiger Name für Ihre Anwendung
    • Homepage-URL: Die vollständige URL der Website Ihrer Anwendung
    • Callback-URL: Die URL, an die Nutzer nach der Autorisierung weitergeleitet werden
    • Scopes: Die Berechtigungen, die Ihre Anwendung benötigt
    • Geräteablauf aktivieren: Standardmäßig deaktiviert. Aktivieren Sie diese Option nur, wenn Ihre Anwendung Nutzer mit einem Gerätecode anmeldet
  4. Generieren Sie nach dem Erstellen der App ein Client Secret. Kopieren und speichern Sie es unbedingt sicher – Sie können es später nicht erneut anzeigen.
Sie erhalten eine Client ID und müssen ein Client Secret generieren. Bewahren Sie diese Zugangsdaten sicher auf und legen Sie sie niemals in clientseitigem Code offen. Bei Verwendung des PKCE-Ablaufs ist kein Client Secret erforderlich.

Verfügbare Scopes

Scopes legen fest, welche Aktionen Ihre OAuth-App ausführen kann. Die verfügbaren Scopes sind nach Ressourcentyp organisiert:
Fordern Sie nur die Scopes an, die Ihre Anwendung tatsächlich benötigt. Nutzer sehen die angeforderten Berechtigungen während der Autorisierung.

OAuth-2.0-Autorisierungscode-Ablauf

Teable implementiert den standardmäßigen OAuth-2.0-Autorisierungscode-Ablauf:

Schritt 1: Nutzer zur Autorisierung weiterleiten

Leiten Sie Nutzer mit den Parametern Ihrer Anwendung an den Autorisierungsendpunkt weiter:
Abfrageparameter: Beispiel:

Schritt 2: Nutzerautorisierung

Nutzer sehen eine Autorisierungsseite mit:
  • Ihrem Anwendungsnamen und Logo
  • Den angeforderten Berechtigungen (Scopes)
  • Optionen zum Genehmigen oder Ablehnen des Zugriffs
Wenn der Nutzer Ihre App zuvor autorisiert hat (standardmäßig innerhalb von 7 Tagen), wird er sofort weitergeleitet, ohne die Autorisierungsseite erneut zu sehen.

Schritt 3: Den Callback verarbeiten

Nachdem der Nutzer genehmigt (oder abgelehnt) hat, leitet Teable zur Callback-URL weiter: Bei Erfolg:
Bei Ablehnung:

Schritt 4: Code gegen Token austauschen

Tauschen Sie den Autorisierungscode gegen Zugriffs- und Aktualisierungstoken aus:
Request-Body: Beispielanfrage:
Antwort:

PKCE-Autorisierungsablauf

PKCE (Proof Key for Code Exchange) wurde für Anwendungen entwickelt, die ein Client Secret nicht sicher speichern können, etwa native Desktop-Apps, mobile Apps, CLI-Tools oder Single-Page-Anwendungen.

Schritt 1: PKCE-Parameter generieren

Vor dem Start der Autorisierung muss der Client ein Paar von PKCE-Parametern generieren:

Schritt 2: Nutzer zur Autorisierung weiterleiten

Abfrageparameter: Beispiel:
Im PKCE-Modus unterstützt redirect_uri Loopback-Adressen (http://127.0.0.1, http://[::1], http://localhost) mit flexibler Portübereinstimmung – Sie müssen nicht jeden Port exakt registrieren.

Schritt 3: Den Callback verarbeiten

Wie beim standardmäßigen Autorisierungscode-Ablauf wird der Autorisierungscode nach der Genehmigung durch den Nutzer per Weiterleitung zurückgegeben.

Schritt 4: Code + code_verifier gegen Token austauschen

Request-Body:
Der PKCE-Modus benötigt kein client_secret. Stattdessen wird der code_verifier verwendet, um die Identität des Clients zu verifizieren.
Beispielanfrage:
Das Antwortformat entspricht dem standardmäßigen Autorisierungscode-Ablauf.

Geräteautorisierungsablauf

Der Geräteautorisierungs-Grant (RFC 8628) ist für Clients gedacht, die keine Browser-Weiterleitung empfangen können: eine über SSH ausgeführte CLI, innerhalb eines Containers oder in einer Cloud-IDE. Ihr Client zeigt eine URL und einen kurzen Code an, der Nutzer genehmigt ihn in einem beliebigen Browser, und es muss nichts zurück in das Terminal eingegeben werden. Teable folgt RFC 8628, daher können die meisten OAuth-Client-Bibliotheken diesen Ablauf ohne benutzerdefinierten Code steuern. Im Folgenden finden Sie die Teable-spezifischen Details.
Der Geräteablauf ist standardmäßig deaktiviert. Aktivieren Sie vor der Nutzung Geräteablauf aktivieren in den Einstellungen Ihrer OAuth-App. Jeder, der Ihre Client ID kennt, kann diesen Ablauf im Namen Ihrer App starten. Aktivieren Sie ihn daher nur, wenn Ihre App ihn benötigt. Wenn Sie ihn wieder deaktivieren, werden auch Anfragen gestoppt, die bereits auf Genehmigung warten.

Einen Gerätecode anfordern

POST /api/oauth/device/code mit Ihrer client_id und einem optionalen scope. Der Endpunkt ist anonym und auf 30 Anfragen pro 15 Minuten und IP-Adresse begrenzt.
Beide Codes laufen nach 15 Minuten ab (BACKEND_OAUTH_DEVICE_CODE_EXPIRE_IN), und interval ist die Mindestanzahl von Sekunden, die zwischen Abfragen gewartet werden muss. Geben Sie die verification_uri und den user_code aus. Auf dieser Seite meldet sich der Nutzer an, gibt den Code ein und überprüft Name, Homepage und angeforderte Scopes Ihrer App, bevor er genehmigt oder ablehnt. Die Seite warnt davor, einen Code zu genehmigen, den sie nicht selbst gestartet haben. Jeder Code kann einmal verwendet werden.
Teable gibt verification_uri_complete nicht zurück, und Ihr Client sollte keine solche URL erstellen. Ein genehmigter Code meldet die genehmigende Person bei ihrem eigenen Teable-Konto an; ein Link, der den Code bereits enthält, ist genau das, worauf Phishing mit Gerätecodes beruht.

Nach Token abfragen

POST /api/oauth/access_token mit grant_type=urn:ietf:params:oauth:grant-type:device_code, dem device_code und Ihrer client_id. Öffentliche Clients senden kein client_secret; vertrauliche Clients fügen es wie in den anderen Abläufen hinzu. Solange niemand den Code genehmigt, antwortet der Endpunkt mit einem Fehler statt mit Token: Sobald der Nutzer genehmigt, entspricht die Antwort der Token-Nutzlast der anderen Abläufe.

Zugriffstoken verwenden

Fügen Sie das Zugriffstoken für API-Anfragen in den Header Authorization ein:
In der Regel besteht der erste Schritt nach dem Abrufen eines Tokens darin, alle Bases abzurufen, auf die der aktuelle Nutzer zugreifen kann:
Dieser Endpunkt gibt alle Bases zurück, für die der aktuelle Nutzer eine Zugriffsberechtigung hat. Sie können die baseId aus der Antwort für nachfolgende API-Aufrufe verwenden.

Zugriffstoken aktualisieren

Wenn ein Zugriffstoken abläuft, verwenden Sie das Aktualisierungstoken, um ein neues abzurufen:
Request-Body: Beispielanfrage:
Nach der Aktualisierung wird das vorherige Aktualisierungstoken ungültig (Refresh-Token-Rotation). Speichern Sie stets das neue Aktualisierungstoken aus der Antwort.

Zugriff widerrufen

Für Inhaber von OAuth-Apps

Widerrufen Sie den Zugriff der App für alle Nutzer (das kann nur der Ersteller der App):
Dadurch werden die Autorisierungsdatensätze und Token aller Nutzer gelöscht, sodass die App vollständig daran gehindert wird, auf die Daten eines Nutzers zuzugreifen.

Für Nutzer

Widerrufen Sie Ihre eigene Autorisierung für eine bestimmte App:
Dadurch werden nur die Zugriffstoken und Aktualisierungstoken des aktuellen Nutzers ungültig, ohne andere Nutzer zu beeinträchtigen. Nutzer können den Zugriff auch über die Einstellungsseite Autorisierte Apps widerrufen.

Für Anwendungen

Anwendungen können ihren eigenen Zugriff mithilfe eines Zugriffstokens widerrufen:
Dieser Endpunkt akzeptiert nur die Zugriffstoken-Authentifizierung, keine Sitzungsauthentifizierung.

Token-Ablauf

Fehlerbehandlung

Häufige Fehlerantworten:

Bewährte Verfahren

  1. Wählen Sie den richtigen Modus: Verwenden Sie den Client-Secret-Modus für Web-Apps mit Backend, den PKCE-Modus für native Apps/CLI/SPA und den Geräteablauf, wenn der Client keine Browser-Weiterleitung empfangen kann
  2. Speichern Sie Secrets sicher: Legen Sie Ihr Client Secret niemals in clientseitigem Code offen
  3. Verwenden Sie den State-Parameter: Schließen Sie immer einen zufälligen state-Parameter ein, um CSRF-Angriffe zu verhindern
  4. Fordern Sie minimale Scopes an: Fordern Sie nur Berechtigungen an, die Ihre Anwendung tatsächlich benötigt
  5. Behandeln Sie Token-Aktualisierungen: Implementieren Sie die automatische Token-Aktualisierung vor dem Ablauf
  6. Sichere Token-Speicherung: Speichern Sie Zugriffs- und Aktualisierungstoken sicher auf Ihrem Server

Vollständige Beispiele

Node.js (Autorisierungscode + Client Secret)

Python (PKCE-Modus für CLI-Tools)

Zuletzt geändert am 4. September 2026