> This page is for Camera to Cloud.
> 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.
# Comment gérer les autorisations
## Vue d’ensemble
Ce guide décrit les procédures de gestion des jetons d’autorisation d’appareil dans Frame.io, notamment l’actualisation, la révocation et les pratiques de stockage sécurisé des jetons.
## Conditions préalables
Consultez le guide [Implémentation C2C : configuration](./implementing-c2c-setting-up) pour garantir la bonne configuration.
Composants essentiels requis :
* un paramètre `client_secret` valide émis par Frame.io ;
* la valeur `client_id` qui vous a été attribuée comme détaillé dans le [guide d’authentification et d’autorisation](./implementing-c2c-authentication-and-authorization) ;
* des informations d’identification `access_token` et `refresh_token` valides.
## Comprendre les jetons d’autorisation
Notre guide précédent sur [l’authentification d’appareil](./implementing-c2c-authentication-and-authorization) décrivait le processus d’obtention des jetons d’autorisation de départ via l’authentification utilisateur. Les jetons d’accès conservent leur fonctionnalité pendant environ 8 heures. Pour éliminer la nécessité d’un couplage fréquent d’appareil, nous implémentons la portée `hors ligne` pour obtenir un jeton d’actualisation avec l’autorisation. Ce jeton d’actualisation permet la génération de nouveaux jetons d’accès à l’expiration.
Les jetons d’actualisation restent valides pendant 14 jours. Cette limite délibérée sur la durée du jeton d’accès améliore la sécurité en minimisant les vulnérabilités potentielles des jetons compromis. Notez que si l’autorisation n’est pas renouvelée avant l’expiration du jeton d’actualisation, une nouvelle authentification utilisateur sera nécessaire.
## Processus de reconduction du jeton d’accès
À l’expiration du jeton d’accès, les requêtes API recevront cette réponse :
```json
{
"code": 401,
"errors": [
{
"code": 401,
"detail": "You are not allowed to access that resource",
"status": 401,
"title": "Not Authorized"
}
],
"message": "Not Authorized"
}
```
Exécutez la commande suivante pour obtenir un nouveau jeton :
```shell
curl -X POST https://api.frame.io/v2/auth/token \
--header 'x-client-version: 2.0.0' \
--form 'client_id=[client_id]' \
--form 'client_secret=[client_secret]' \
--form 'grant_type=refresh_token' \
--form 'refresh_token=[refresh_token]' \
| python -m json.tool
```
La documentation détaillée pour `/v2/auth/token` est disponible [ici](/camera-to-cloud/api-reference/authentication/auth-device-token).
Cette implémentation nécessite plusieurs facteurs d’authentification pour améliorer la sécurité. Une partie non autorisée doit obtenir à la fois les paramètres `refresh_token` et `client_secret` pour effectuer votre intégration avec succès.
Une reconduction réussie génère cette réponse :
```json
{
"access_token": "[access_token]",
"expires_in": 28800,
"refresh_token": "[refresh_token]",
"token_type": "bearer"
}
```
Lors de l’actualisation réussie du jeton, les informations d’identification précédentes deviennent non valides. Assurez-vous de stocker correctement les nouveaux jetons d’autorisation.
Tenter de réutiliser un jeton d’actualisation expiré entraîne la réponse suivante :
```json
{
"error": "invalid_request"
}
```
Cela indique que le jeton a été traité précédemment et n’est plus valide.
La réception d’une réponse `401 Not Authorized` lors de l’actualisation du jeton indique l’invalidation des informations d’identification, nécessitant un nouveau processus d’autorisation.
## Gestion des réponses d’actualisation échouées
En raison de la nature à usage unique des valeurs `refresh_token`, l’échec de capture de la réponse d’actualisation, que ce soit en raison d’une interruption du réseau ou d’un arrêt du système, nécessite de relancer la séquence complète d’authentification/autorisation.
Ce protocole de sécurité, bien que potentiellement gênant, est essentiel pour maintenir l’intégrité du système.
## Processus de révocation de jeton
Les circonstances peuvent nécessiter la résiliation de l’accès Frame.io, comme l’achèvement du projet ou la réinitialisation de l’application. Implémentez des procédures de révocation appropriées lors de l’arrêt de l’autorisation actuelle.
Exécutez la commande suivante pour révoquer l’autorisation :
Après révocation, vous devez relancer le processus d’authentification et d’autorisation comme décrit dans le [guide d’authentification et d’autorisation](./implementing-c2c-authentication-and-authorization).
```shell
curl -X POST https://api.frame.io/v2/auth/revoke \
--include \
--header 'x-client-version: 2.0.0' \
--form 'client_id=[client_id]' \
--form 'client_secret=[client_secret]' \
--form 'token=[refresh_token]'
```
La documentation complète pour `/v2/auth/revoke` est disponible [ici](/camera-to-cloud/api-reference/authentication/auth-device-revoke-token).
Le système renvoie des en-têtes sans payload. Le succès est indiqué par un code d’état `200` :
```text
HTTP/2 200
...
```
Après révocation, les opérations Frame.io nécessitant une authentification `access_token` renverront la réponse `Not Authorized`. La restauration de l’accès nécessite un nouveau couplage de l’appareil au projet.
## Implémentation du stockage de jetons
Conserver une autorisation persistante lors des redémarrages système nécessite un stockage sécurisé des jetons. Respectez les consignes suivantes :
**Implémenter les contrôles d’accès utilisateur :** limitez la visibilité et l’accès des jetons exclusivement aux processus d’application. **Activer le chiffrement du stockage :** implémentez un chiffrement pour les jetons stockés, y compris `client_secret` et les informations d’identification d’autorisation. Ne conservez jamais les clés d’autorisation au format texte brut. **Maintenir la séparation des informations d’identification :** bien que notre application Python de démonstration consolide le stockage, les environnements de production doivent séparer les jetons d’autorisation de `client_secret`. Tenez compte de ces facteurs :
* `client_secret` et `client_id` représentent les informations d’identification permanentes de l’appareil. Leur perte entraîne une défaillance permanente de l’appareil.
* Les jetons d’autorisation subissent des mises à jour régulières tout au long du fonctionnement de l’appareil.
* Le stockage séparé garantit que la corruption du stockage des jetons nécessite uniquement un recouplage de l’appareil, plutôt qu’une réinitialisation complète de l’authentification.
Bien que SQLite offre des capacités de stockage de jetons optimales, implémentez au minimum un stockage séparé pour les données d’autorisation et les informations d’identification principales.
## Étapes suivantes
Nous vous félicitons pour votre progression et vous invitons à passer au [guide du statut de connexion et des pulsations](./how-to-heartbeats-connection-info-and-status). Veuillez contacter notre équipe pour toute question ou préoccupation.