- 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
- Gehen Sie in Ihrem Teable-Konto zu Einstellungen > OAuth-Apps.
- Klicken Sie auf Neue OAuth-Apps, um eine neue Anwendung zu erstellen.
-
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
- 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: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:
Beispiel:
Schritt 2: Nutzerautorisierung
Nutzer sehen eine Autorisierungsseite mit:- Ihrem Anwendungsnamen und Logo
- Den angeforderten Berechtigungen (Scopes)
- Optionen zum Genehmigen oder Ablehnen des Zugriffs
Schritt 3: Den Callback verarbeiten
Nachdem der Nutzer genehmigt (oder abgelehnt) hat, leitet Teable zur Callback-URL weiter: Bei Erfolg:Schritt 4: Code gegen Token austauschen
Tauschen Sie den Autorisierungscode gegen Zugriffs- und Aktualisierungstoken aus:
Beispielanfrage:
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
Beispiel:
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
Der PKCE-Modus benötigt kein
client_secret. Stattdessen wird der code_verifier verwendet, um die Identität des Clients zu verifizieren.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.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.
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 HeaderAuthorization ein:
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:
Beispielanfrage:
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):Für Nutzer
Widerrufen Sie Ihre eigene Autorisierung für eine bestimmte App: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
- 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
- Speichern Sie Secrets sicher: Legen Sie Ihr Client Secret niemals in clientseitigem Code offen
- Verwenden Sie den State-Parameter: Schließen Sie immer einen zufälligen
state-Parameter ein, um CSRF-Angriffe zu verhindern - Fordern Sie minimale Scopes an: Fordern Sie nur Berechtigungen an, die Ihre Anwendung tatsächlich benötigt
- Behandeln Sie Token-Aktualisierungen: Implementieren Sie die automatische Token-Aktualisierung vor dem Ablauf
- Sichere Token-Speicherung: Speichern Sie Zugriffs- und Aktualisierungstoken sicher auf Ihrem Server

