Skip to main content
Le app OAuth consentono alle applicazioni di terze parti di accedere a Teable per conto degli utenti. Questa guida spiega come creare e configurare un’app OAuth, implementare il flusso di autorizzazione OAuth 2.0 e utilizzare i token di accesso per interagire con l’API di Teable. Teable supporta tre modalità di autorizzazione OAuth 2.0:
  • Codice di autorizzazione + Segreto client: per le applicazioni web dotate di server backend
  • Codice di autorizzazione + PKCE: per app native, strumenti CLI, SPA e altri client pubblici che non possono archiviare in modo sicuro un segreto client
  • Concessione di autorizzazione del dispositivo: per i client che non possono ricevere alcun reindirizzamento del browser, ad esempio una CLI eseguita tramite SSH, in un container o in un IDE cloud

Creare un’app OAuth

  1. Nel tuo account Teable, vai a Impostazioni > App OAuth.
  2. Fai clic su Nuova app OAuth per creare una nuova applicazione.
  3. Compila le informazioni richieste:
    • Nome dell’app OAuth: un nome descrittivo per l’applicazione
    • URL della home page: l’URL completo del sito web dell’applicazione
    • URL di callback: l’URL al quale verranno reindirizzati gli utenti dopo l’autorizzazione
    • Ambiti: le autorizzazioni necessarie all’applicazione
    • Abilita flusso del dispositivo: disattivato per impostazione predefinita. Attivalo soltanto se l’applicazione esegue l’accesso degli utenti tramite un codice dispositivo
  4. Dopo aver creato l’app, genera un Segreto client. Assicurati di copiarlo e conservarlo in modo sicuro: non potrai visualizzarlo di nuovo.
Riceverai un ID client e dovrai generare un Segreto client. Conserva queste credenziali in modo sicuro e non esporle mai nel codice lato client. Se utilizzi il flusso PKCE, il segreto client non è necessario.

Ambiti disponibili

Gli ambiti definiscono le azioni che l’app OAuth può eseguire. Gli ambiti disponibili sono organizzati per tipo di risorsa:
Richiedi soltanto gli ambiti effettivamente necessari all’applicazione. Durante l’autorizzazione, gli utenti vedranno le autorizzazioni richieste.

Flusso del codice di autorizzazione OAuth 2.0

Teable implementa il flusso standard del codice di autorizzazione OAuth 2.0:

Passaggio 1: reindirizzare gli utenti all’autorizzazione

Indirizza gli utenti all’endpoint di autorizzazione con i parametri della tua applicazione:
Parametri di query: Esempio:

Passaggio 2: autorizzazione dell’utente

Gli utenti vedranno una pagina di autorizzazione contenente:
  • Il nome e il logo dell’applicazione
  • Le autorizzazioni richieste (ambiti)
  • Le opzioni per approvare o negare l’accesso
Se l’utente ha già autorizzato l’app in precedenza (per impostazione predefinita, negli ultimi 7 giorni), verrà reindirizzato immediatamente senza visualizzare nuovamente la pagina di autorizzazione.

Passaggio 3: gestire il callback

Dopo l’approvazione (o il rifiuto) dell’utente, Teable reindirizza all’URL di callback: In caso di successo:
In caso di rifiuto:

Passaggio 4: scambiare il codice con i token

Scambia il codice di autorizzazione con i token di accesso e di aggiornamento:
Corpo della richiesta: Richiesta di esempio:
Risposta:

Flusso di autorizzazione PKCE

PKCE (Proof Key for Code Exchange) è progettato per le applicazioni che non possono archiviare in modo sicuro un segreto client, ad esempio app desktop native, app mobili, strumenti CLI o applicazioni a pagina singola.

Passaggio 1: generare i parametri PKCE

Prima di avviare l’autorizzazione, il client deve generare una coppia di parametri PKCE:

Passaggio 2: reindirizzare gli utenti all’autorizzazione

Parametri di query: Esempio:
In modalità PKCE, redirect_uri supporta gli indirizzi di loopback (http://127.0.0.1, http://[::1], http://localhost) con corrispondenza flessibile della porta: non è necessario registrare ogni porta esatta.

Passaggio 3: gestire il callback

Come nel flusso standard del codice di autorizzazione: dopo l’approvazione dell’utente, il codice di autorizzazione viene restituito tramite reindirizzamento.

Passaggio 4: scambiare il codice + code_verifier con i token

Corpo della richiesta:
La modalità PKCE non richiede client_secret. Al suo posto viene utilizzato code_verifier per verificare l’identità del client.
Richiesta di esempio:
Il formato della risposta è identico a quello del flusso standard del codice di autorizzazione.

Flusso di autorizzazione del dispositivo

La concessione di autorizzazione del dispositivo (RFC 8628) è destinata ai client che non possono ricevere un reindirizzamento del browser: una CLI eseguita tramite SSH, all’interno di un container o in un IDE cloud. Il client mostra un URL e un breve codice, l’utente approva in qualsiasi browser e non deve digitare nulla nel terminale. Teable segue la specifica RFC 8628, pertanto la maggior parte delle librerie client OAuth può gestire questo flusso senza codice personalizzato. Di seguito sono riportati gli aspetti specifici di Teable.
Il flusso del dispositivo è disattivato per impostazione predefinita. Prima di utilizzarlo, attiva Abilita flusso del dispositivo nelle impostazioni dell’app OAuth. Chiunque conosca il tuo ID client può avviare questo flusso a nome della tua app, quindi abilitalo soltanto se è necessario. Disattivandolo nuovamente, verranno interrotte anche le richieste già in attesa di approvazione.

Richiedere un codice dispositivo

POST /api/oauth/device/code con il tuo client_id e un scope facoltativo. L’endpoint è anonimo e soggetto a un limite di frequenza di 30 richieste ogni 15 minuti per indirizzo IP.
Entrambi i codici scadono dopo 15 minuti (BACKEND_OAUTH_DEVICE_CODE_EXPIRE_IN) e interval indica il numero minimo di secondi da attendere tra i tentativi di polling. Mostra verification_uri e user_code. In quella pagina l’utente accede, inserisce il codice ed esamina il nome dell’app, la home page e gli ambiti richiesti prima di approvare o rifiutare. La pagina avverte di non approvare un codice la cui procedura non è stata avviata personalmente. Ogni codice può essere utilizzato una sola volta.
Teable non restituisce verification_uri_complete e il client non deve crearne uno. Un codice approvato consente all’utente che lo approva di accedere al proprio account Teable, pertanto un link che contiene già il codice è esattamente ciò su cui si basa il phishing tramite codice dispositivo.

Eseguire il polling per ottenere i token

POST /api/oauth/access_token con grant_type=urn:ietf:params:oauth:grant-type:device_code, il device_code e il tuo client_id. I client pubblici non inviano alcun client_secret; i client riservati lo aggiungono come negli altri flussi. Finché qualcuno non approva il codice, l’endpoint risponde con un errore anziché con i token: Dopo l’approvazione dell’utente, la risposta contiene lo stesso payload di token degli altri flussi.

Utilizzare i token di accesso

Includi il token di accesso nell’header Authorization delle richieste API:
In genere, il primo passaggio dopo aver ottenuto un token consiste nel recuperare tutte le Base accessibili all’utente corrente:
Questo endpoint restituisce tutte le Base a cui l’utente corrente è autorizzato ad accedere. Puoi utilizzare il baseId presente nella risposta per le chiamate API successive.

Aggiornare i token di accesso

Quando un token di accesso scade, utilizza il token di aggiornamento per ottenerne uno nuovo:
Corpo della richiesta: Richiesta di esempio:
Dopo l’aggiornamento, il token di aggiornamento precedente perde validità (rotazione del token di aggiornamento). Archivia sempre il nuovo token di aggiornamento restituito nella risposta.

Revocare l’accesso

Per i proprietari di app OAuth

Revoca l’accesso dell’app per tutti gli utenti (soltanto l’autore dell’app può farlo):
Questa operazione elimina i record di autorizzazione e i token di tutti gli utenti, impedendo completamente all’app di accedere ai dati di qualsiasi utente.

Per gli utenti

Revoca la tua autorizzazione per una determinata app:
Questa operazione invalida soltanto i token di accesso e di aggiornamento dell’utente corrente, senza influire sugli altri utenti. Gli utenti possono revocare l’accesso anche tramite la pagina delle impostazioni App autorizzate.

Per le applicazioni

Le applicazioni possono revocare il proprio accesso utilizzando un token di accesso:
Questo endpoint accetta soltanto l’autenticazione con token di accesso, non l’autenticazione della sessione.

Scadenza dei token

Gestione degli errori

Risposte di errore comuni:

Procedure consigliate

  1. Scegli la modalità corretta: usa la modalità con segreto client per le app web dotate di backend, la modalità PKCE per app native, CLI o SPA e il flusso del dispositivo quando il client non può ricevere un reindirizzamento del browser
  2. Archivia i segreti in modo sicuro: non esporre mai il Segreto client nel codice lato client
  3. Usa il parametro state: includi sempre un parametro casuale state per prevenire attacchi CSRF
  4. Richiedi gli ambiti minimi: richiedi soltanto le autorizzazioni effettivamente necessarie all’applicazione
  5. Gestisci l’aggiornamento dei token: implementa l’aggiornamento automatico dei token prima della scadenza
  6. Proteggi l’archiviazione dei token: archivia in modo sicuro sul server i token di accesso e di aggiornamento

Esempi completi

Node.js (Codice di autorizzazione + Segreto client)

Python (modalità PKCE per strumenti CLI)

Ultima modifica il 4 settembre 2026