> This page is for Piattaforma, version Versione precedente.
> For other versions, use one of these documentation indexes:
> - V4 (default): https://next.developer.frame.io/platform/v4/llms.txt
> - V4 sperimentale: https://next.developer.frame.io/platform/v4-experimental/llms.txt
> - Versione precedente: https://next.developer.frame.io/platform/v2/llms.txt

> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://next.developer.frame.io/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://next.developer.frame.io/_mcp/server.

# Flusso di autorizzazione del codice OAuth 2

## Panoramica

Frame.io supporta la creazione e la gestione di applicazioni OAuth 2. A differenza dei [token sviluppatore](/getting-started/authentication#developer-tokens), le app OAuth 2 consentono a qualsiasi utente Frame.io di concedere le proprie credenziali tramite login sicuro, dopodiché l'app può agire per conto di tale utente.

In parole semplici, le app OAuth 2 sono ideali per qualsiasi scenario di integrazione in cui il contesto e l'accesso di un singolo utente sono importanti.





## Flusso del codice OAuth 2




### Sequenza di base




A livello molto generale, OAuth 2 ha tre aspetti principali:



1. L'**utente** (nel nostro caso, chiunque abbia un accesso Frame.io)
2. L'**applicazione** client (l'app OAuth2.0 esterna)
3. Il **server** delle credenziali (nel nostro caso, Frame.io)





Il flusso del codice per OAuth 2 è un processo in quattro fasi attraverso il quale:



1. L'**applicazione** presenta all'**utente** una schermata di accesso
2. L'**utente** inserisce le proprie credenziali, che vanno direttamente al **server**
3. Se l'accesso riesce, il **server** mostra una pagina in cui viene chiesto all'**utente** di confermare se vuole concedere un set preconfigurato di ambiti di accesso all'**applicazione**
4. Se l'**utente** acconsente, il **server** invia all'**applicazione** un token che può essere utilizzato per agire per conto dell'**utente** con gli ambiti richiesti.





In questo modo, un'applicazione client può agire per conto dell'utente in modo sicuro, con il permesso dell'utente e, aspetto molto importante, senza mai vedere o gestire le credenziali effettive dell'utente.





### Ciclo di callback




La sequenza descritta in alto si basa sul server (Frame.io) che ospita due servizi, ciascuno con il proprio instradamento:




| Servizio | URL | Metodo | Descrizione |
| ---------- | ---------- | ---------- | ---------- |
| Autenticazione | `https://applications.frame.io/oauth2/auth` | `GET` | In base delle informazioni sull'applicazione client OAuth, avvia il flusso di autorizzazione con il server. |
| Token | `https://applications.frame.io/oauth2/token` | `POST` | In base alle informazioni del passaggio di autorizzazione, recupera un token per conto dell'utente. |




Il ruolo dell'applicazione OAuth 2 in questo ciclo è identificarsi nel server ed effettuare quelle due richieste.





## Esempio rapido



<Info title="Hai già creato un'app OAuth 2?">
  Se conosci già il resto dell'infrastruttura per OAuth2.0, l'esempio qui sotto potrebbe essere sufficiente per iniziare. Se desideri maggiori dettagli, consulta una guida più dettagliata [qui](/oauth-2-applications/building-an-oauth2-app).
</Info>


### Configurazione dell'app



1. Accedi al [Frame.io Developer Portal](/) con le tue credenziali Frame.io, vai a **OAuth Apps** utilizzando i link nella barra laterale sinistra e fai clic su **New** per iniziare a configurare la tua app.
2. Nella schermata successiva, inserisci un **nome** e un **URI di reindirizzamento** per la tua app, seleziona gli **ambiti** e scegli se utilizzare **PKCE**.
3. Dopo aver salvato, dovresti vedere la configurazione della tua nuova app.




<Info title="Informazioni su PKCE">
  L'impostazione **P**roof **K**ey for **C**ode **E**xchange (&quot;pixie&quot;) consentirà alla tua app di richiedere token senza fornire il suo `client_secret`. Di conseguenza, non ti verrà fornito un `client_secret` e non dovresti includere un'intestazione `Authorization` quando effettui un `POST` per un token nel ciclo di callback dell'app. Detto questo, **dovrai includere il tuo `client_id` nel callback**, altrimenti la tua richiesta verrà rifiutata.
</Info>


#### Quando bisogna usare PKCE?




In generale, non ci sono effetti collaterali negativi nell'utilizzo di PKCE, anzi è l'approccio consigliato e preferito. Quando sviluppi un'applicazione client OAuth2.0, devi implementare il flusso di autorizzazione del codice in uno di questi due contesti:

- **Privato**: il flusso è implementato in un linguaggio lato server (Python, Java) e puoi gestire in modo sicuro il tuo `client_secret` in un server che controlli. - **Pubblico**: il flusso è implementato in un linguaggio lato client (JavaScript) o direttamente su un dispositivo client controllato dall'utente finale (iOS, Android).

Come regola generale, puoi considerare un'applicazione &quot;pubblica&quot; se tu (ovvero lo sviluppatore dell'applicazione) non puoi vedere e controllare tutto il traffico di rete relativo allo scambio di secret. Questo significa che, oltre alle applicazioni lato client, le applicazioni per dispositivi mobili, i dispositivi incorporati o qualsiasi dispositivo che si trova nella rete di un utente finale (AppleTV, Roku ecc.) dovrebbero essere considerati pubblici.





In contesti privati, *puoi* utilizzare PKCE. In contesti pubblici, *devi* utilizzare PKCE.





## Creazione dell'applicazione OAuth 2




Ora che hai una configurazione dell'app in Frame.io, puoi procedere con la configurazione del server di callback per gestire i due instradamenti chiave e completare il ciclo di callback, come indicato nella tabella in alto.

Per informazioni più dettagliate su come sviluppare l'applicazione, scopri come [creare un'app OAuth 2](/oauth-2-applications/building-an-oauth2-app).