> This page is for Plate-forme, version Hérité.
> For other versions, use one of these documentation indexes:
> - V4 (default): https://next.developer.frame.io/platform/v4/llms.txt
> - V4 expérimental: https://next.developer.frame.io/platform/v4-experimental/llms.txt
> - Hérité: 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.
# Flux d'autorisation de code OAuth 2
## Vue d'ensemble
Frame.io prend en charge la création et la gestion d'applications OAuth 2. Contrairement aux [jetons de développeur](/getting-started/authentication#developer-tokens), les applications OAuth 2 permettent à n'importe quel Utilisateur Frame.io d'octroyer ses informations d'identification via une connexion sécurisée, après quoi l'Application peut agir au nom de cet Utilisateur.
En termes simples, les applications OAuth 2 sont idéales pour tout scénario d'intégration dans lequel le contexte et l'accès d'un Utilisateur individu sont importants.
## Flux de code OAuth 2
### La séquence de base
À un niveau très élevé, OAuth 2 compte trois parties :
1. L'**Utilisateur** (dans notre cas : toute personne disposant d'un Nom d'utilisateur Frame.io)
2. L'**Application** cliente (l'Application OAuth2.0 externe)
3. Le **Serveur** d'informations d'identification (dans notre cas : Frame.io)
Le flux de code pour OAuth 2 est un processus en quatre étapes au cours duquel :
1. L'**Application** présente à l'**Utilisateur** un écran de connexion
2. L'**Utilisateur** saisit ses informations d'identification, qui vont directement au **Serveur**
3. Si la connexion réussit, le **Serveur** renvoie une page demandant à l'**Utilisateur** de confirmer qu'il souhaite octroyer un ensemble préconfiguré de portées d'accès à l'**Application**
4. Si l'**Utilisateur** consent, le **Serveur** envoie à l'**Application** un jeton qui peut être utilisé pour agir au nom de l'**Utilisateur** avec les portées demandées.
De cette manière, une Application cliente peut prendre des mesures au nom de l'Utilisateur, en toute sécurité, avec l'autorisation de l'Utilisateur et (surtout) sans jamais voir ni gérer les informations d'identification réelles de l'Utilisateur.
### Le cycle de rappel
La séquence ci-dessus repose sur le Serveur (Frame.io) hébergeant deux services, chacun avec sa propre route :
| Service | URL | Méthode | Description |
| ---------- | ---------- | ---------- | ---------- |
| Authentification | `https://applications.frame.io/oauth2/auth` | `GET` | À partir des informations sur l'application client OAuth, lance le flux d'authentification avec le serveur. |
| Jeton | `https://applications.frame.io/oauth2/token` | `POST` | À partir des informations de l'étape d'authentification, récupère un jeton au nom de l'utilisateur. |
Le rôle de l'application OAuth 2 dans ce cycle est de s'identifier auprès du serveur et d'effectuer ces deux requêtes.
## Exemple rapide
Si vous connaissez déjà le fonctionnement d'OAuth2.0, l'exemple ci-dessous peut suffire pour commencer.Si vous souhaitez un peu plus de détails, consultez le guide plus détaillé [ici](/oauth-2-applications/building-an-oauth2-app).
### Configuration de votre application
1. Connectez-vous au [Frame.io Developer Portal](/) avec vos identifiants Frame.io, accédez à **OAuth Apps** à l'aide des liens dans la partie gauche, puis cliquez sur **Nouveau** pour commencer à configurer votre application.
2. Dans l'écran suivant, saisissez un **Nom** et un **URI de redirection** pour votre application, sélectionnez vos **Portées**, puis choisissez d'utiliser **PKCE** ou non.
3. Enregistrez : vous devriez maintenant voir la configuration de votre nouvelle application.
Le paramètre **P**roof **K**ey for **C**ode **E**xchange (« pixie ») permet à votre application de demander des jetons sans fournir son `client_secret`.Par conséquent, aucun `client_secret` ne vous sera fourni et vous ne devez pas inclure d'en-tête `Authorization` lors de l'envoi `POST` pour un jeton dans le cycle de rappel de votre application.Cela dit, vous **devez inclure votre `client_id` dans votre rappel**, sinon votre requête sera refusée.
#### Quand dois-je utiliser PKCE ?
En général, l'utilisation de PKCE n'a aucun effet secondaire négatif et constitue l'approche recommandée et privilégiée.Lors du développement d'une application client OAuth2.0, vous implémenterez le flux d'autorisation de code dans l'un des deux contextes suivants :
- **Privé** : votre flux est implémenté dans un langage côté serveur (Python, Java) et vous pouvez gérer en toute sécurité votre `client_secret` dans un serveur que vous contrôlez.- **Public** : votre flux est implémenté dans un langage côté client (JavaScript) ou directement sur un appareil client contrôlé par un utilisateur final (iOS, Android).
En règle générale, vous pouvez considérer une application comme « publique » si vous, en tant que développeur de l'application, ne pouvez pas voir et contrôler tout le trafic réseau lié à l'échange de secrets. Cela signifie qu'en plus des applications côté client, les applications d'appareil mobile, les appareils intégrés ou tout appareil qui se trouve sur le réseau d'un utilisateur final (AppleTV, Roku, etc.) doivent être considérés comme publics.
Dans les contextes privés, vous *pouvez* utiliser PKCE. Dans les contextes publics, vous *devez* utiliser PKCE.
## Création de votre application OAuth 2
Maintenant que vous avez une configuration d'app dans Frame.io, vous pouvez configurer votre serveur de rappel pour gérer les deux routes principales afin de compléter le cycle de rappel, selon le tableau ci-dessus.
Pour des informations plus détaillées sur la création de votre application, veuillez consulter [Création d'une app OAuth 2](/oauth-2-applications/building-an-oauth2-app).