- 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
- Nel tuo account Teable, vai a Impostazioni > App OAuth.
- Fai clic su Nuova app OAuth per creare una nuova applicazione.
-
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
- 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: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:
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
Passaggio 3: gestire il callback
Dopo l’approvazione (o il rifiuto) dell’utente, Teable reindirizza all’URL di callback: In caso di successo:Passaggio 4: scambiare il codice con i token
Scambia il codice di autorizzazione con i token di accesso e di aggiornamento:
Richiesta di esempio:
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
Esempio:
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
La modalità PKCE non richiede
client_secret. Al suo posto viene utilizzato code_verifier per verificare l’identità del client.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.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.
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’headerAuthorization delle richieste API:
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:
Richiesta di esempio:
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):Per gli utenti
Revoca la tua autorizzazione per una determinata app: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
- 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
- Archivia i segreti in modo sicuro: non esporre mai il Segreto client nel codice lato client
- Usa il parametro state: includi sempre un parametro casuale
stateper prevenire attacchi CSRF - Richiedi gli ambiti minimi: richiedi soltanto le autorizzazioni effettivamente necessarie all’applicazione
- Gestisci l’aggiornamento dei token: implementa l’aggiornamento automatico dei token prima della scadenza
- Proteggi l’archiviazione dei token: archivia in modo sicuro sul server i token di accesso e di aggiornamento

