SDK Python Frame.io — Guida all’autenticazione
SDK Python Frame.io — Guida all’autenticazione
Questa guida spiega come eseguire l’autenticazione con l’API Frame.io usando l’SDK Python Frame.io (frameio). L’API V4 Frame.io usa Adobe Identity Management Service (IMS), la piattaforma di identità OAuth 2.0 di Adobe. Si tratta di un riferimento autonomo per sviluppatori Python. Tutti gli esempi di codice e i flussi seguenti sono solo per il pacchetto frameio.
Tipi di autenticazione nell’SDK Python
L’SDK Python supporta quattro opzioni di autenticazione:
La credenziale dell’app nativa di Adobe richiede dei gestori di schema URI personalizzati (ad esempio adobe+<hash>://…</hash>) che intercettano i reindirizzamenti a livello del sistema operativo. Python non ha un modo standard per registrare tali gestori, quindi l’SDK Python non offre una classe NativeAppAuth. Per le applicazioni Python interattive, usa WebAppAuth con un server di callback locale (ad esempio Flask o FastAPI). Per i carichi di lavoro non interattivi, usa ServerToServerAuth.
Utenti dell’account di servizio
Quando usi l’autenticazione server-to-server, l’applicazione agisce come utente dell’account di servizio, un tipo di account distinto che può eseguire azioni per conto del servizio. Questi sono visibili agli altri utenti in Frame.io: quando un account di servizio esegue un’azione, il nome viene visualizzato nell’interfaccia utente. Puoi concedere e revocare l’accesso dell’account di servizio tramite Adobe Admin Console e Developer Console. I nomi degli account di servizio vengono gestiti dall’interfaccia utente Frame.io. Per impostazione predefinita, la prima connessione S2S viene denominata Service Account User, la seconda Service Account User 2 e così via.
Consulta Automatizza la configurazione usando il supporto server-to-server di Frame.io per ulteriori informazioni.
Avvio rapido
Prerequisiti
- Credenziali da Adobe Developer Console:
- ID client: richiesto per tutti i flussi OAuth - Secret client: richiesto per i flussi server-to-server e web app - URI di reindirizzamento: richiesto per i flussi web app e SPA; deve essere registrato nel progetto Adobe
- Installa l’SDK:
Scelta di un metodo
- Non è coinvolto nessun utente? Usa server-to-server (
ServerToServerAuth). - È coinvolto un utente e puoi archiviare un secret? Usa web app (
WebAppAuth). - È coinvolto un utente, ma non puoi archiviare un secret? Usa SPA (
SPAAuth).
Token di accesso
Se hai già un token di accesso (da un altro sistema OAuth o da uno scambio precedente, ad esempio tramite il nostro Explorer di API) puoi passarlo direttamente:
Questo è l’approccio più semplice, ma il token scadrà e l’SDK non lo aggiornerà automaticamente.
Token sviluppatore legacy
Per gli account migrati a V4 e non ancora amministrati tramite Adobe Admin Console, puoi continuare a utilizzare i token sviluppatore legacy dal sito per sviluppatori di Frame.io. Devi includere l’intestazione x-frameio-legacy-token-auth e impostarla su true:
I token sviluppatore legacy non scadono, ma sono un meccanismo di transizione. Per le nuove integrazioni e i carichi di lavoro di produzione, consigliamo di utilizzare uno dei flussi OAuth 2.0 indicati di seguito. Consulta la guida alla migrazione per i dettagli.
Server-to-server (credenziali client)
Utilizza questo metodo per servizi e script backend che necessitano dell’accesso a Frame.io senza interazioni da parte dell’utente. Questo flusso è disponibile solo per gli account Frame.io V4 amministrati tramite Adobe Admin Console. La tua applicazione si autentica come utente dell’account di servizio senza intervento umano.
Sync
Async
Ecco fatto. auth.get_token è una funzione che l’SDK richiama a ogni richiesta. Se il token corrente è ancora valido, restituisce immediatamente il risultato. Se sta per scadere, ne recupera prima uno nuovo, in modo completamente trasparente.
Come funziona
Le tue credenziali client (ID client + secret) non scadono mai. Basta ruotarle manualmente per garantire l’integrità della sicurezza. S2S offre un accesso API permanente e ininterrotto senza alcun intervento manuale.
Dietro le quinte:
- Alla prima chiamata API,
get_tokenrichiede un nuovo token di accesso da Adobe IMS utilizzando la concessioneclient_credentials. - Il token viene memorizzato nella cache in memoria. I singoli token di accesso scadono (in genere 24 ore), ma questo viene gestito automaticamente.
- Quando un token memorizzato nella cache si trova entro il buffer di aggiornamento (predefinito: 60 secondi prima della scadenza), l’SDK ne recupera automaticamente uno nuovo utilizzando le stesse credenziali client.
- Non sono coinvolti token di aggiornamento. Le credenziali client stesse sono il secret di lunga durata e possono sempre essere utilizzate per generare un nuovo token di accesso.
Autenticazione esplicita
Se desideri recuperare il token in modo proattivo (ad esempio, per generare rapidamente un errore in caso di credenziali errate all’avvio):
Web app (codice di autorizzazione)
Utilizza questo metodo per applicazioni lato server in cui gli utenti accedono con il proprio Adobe ID. Questo flusso richiede un client secret, che deve essere archiviato in modo sicuro sul server.
Gestisci il callback
Quando Adobe IMS reindirizza l’utente al tuo redirect_uri, estrai i parametri code e state.Verifica che lo stato corrisponda a quello che hai archiviato, quindi scambia il codice con i token:
Sync
Async
Questa operazione scambia il codice di autorizzazione con un token di accesso e un token di aggiornamento, archiviandoli entrambi internamente.
Esempio completo di Flask
App a singola pagina/PKCE (codice di autorizzazione + PKCE)
Utilizza questa opzione per applicazioni basate su browser, applicazioni desktop o strumenti CLI che non possono archiviare in modo sicuro un secret del client. Questo flusso utilizza PKCE (RFC 7636) per proteggere lo scambio del codice di autorizzazione.
Utilizzo asincrono
Ogni classe di autenticazione ha una controparte asincrona con prefisso Async. Gli esempi di codice in alto includono le schede Sync e Async, ove applicabile.
Aggiornamento manuale del token
Per i flussi di web app e SPA, l’SDK aggiorna automaticamente i token tramite get_token. Se hai bisogno di un controllo esplicito, puoi chiamare direttamente refresh():
Sync
Async
Questo è utile quando vuoi forzare un aggiornamento prima di un’operazione critica anziché affidarti al buffer di aggiornamento automatico.
Persistenza del token
Tutte le classi di autenticazione supportano export_tokens() e import_tokens() per mantenere lo stato del token durante i riavvii. Questo è particolarmente importante per i flussi di web app e SPA, poiché i token di accesso e di aggiornamento risiedono in memoria per impostazione predefinita. Se l’applicazione si riavvia, gli utenti dovrebbero autenticarsi nuovamente, a meno che non li rendi persistenti. Per gli scenari server-to-server, la persistenza è facoltativa (le credenziali client possono sempre generare un nuovo token), ma l’importazione di un token memorizzato in cache evita un round-trip aggiuntivo all’avvio.
Esportazione e importazione
Persistenza automatica con on_token_refreshed
Per rendere automaticamente persistenti i token ogni volta che vengono aggiornati, usa il callback on_token_refreshed:
Il callback riceve la stessa forma di dict di export_tokens() e si attiva dopo ogni aggiornamento riuscito del token.Per le classi async, on_token_refreshed può essere una funzione normale o una funzione async. Sono supportate entrambe.
Revoca dei token
Per disconnettere un utente e invalidare i suoi token con Adobe IMS:
Esegue una richiesta di revoca best-effort ad Adobe IMS sia per il token di accesso che per il token di aggiornamento, quindi cancella tutto lo stato dei token locali. Dopo la revoca, l’utente dovrà autenticarsi di nuovo.
Per le classi async, usa await auth.revoke().
Gestione degli errori
Tutti gli errori di autenticazione ereditano da FrameioAuthError, quindi puoi intercettarli in modo generale o gestire casi specifici:
Riferimento dell’errore
Gestione dei token di aggiornamento scaduti in produzione
Per i flussi di web app e SPA, il token di aggiornamento scadrà.Quando ciò accade, get_token genera TokenExpiredError. Devi intercettare questo errore e reindirizzare l’utente attraverso il flusso di autorizzazione.
Riferimento della configurazione
Tutte le classi di autorizzazione accettano questi parametri opzionali:
Riferimento dei parametri
Ambienti temporanei
Punta a un’istanza Adobe IMS temporanea sostituendo ims_base_url. L’SDK esporta anche DEFAULT_IMS_BASE_URL (https://ims-na1.adobelogin.com) se devi fare riferimento al valore di produzione a livello programmatico.
Client HTTP personalizzato
Per il supporto proxy o la configurazione TLS personalizzata:
Sicurezza dei thread
Le classi di autenticazione sincronizzate sono completamente thread-safe. Se più thread chiamano get_token contemporaneamente ed è necessario un aggiornamento, solo un thread esegue l’aggiornamento. Gli altri attendono e ricevono lo stesso risultato. Non è richiesto alcun blocco esterno. Le classi asincrone offrono la stessa garanzia utilizzando asyncio.Lock, sicuro per coroutine simultanee all’interno di un singolo ciclo di eventi.