Authentification serveur

Une seule clé côté serveur

Chaque requête canonique utilise une clé Orbit propre à l’environnement ciblé :

Authorization: Bearer <ORBIT_ENVIRONMENT_API_KEY>

Cette clé identifie l’accès commercial, ses permissions et ses quotas. Le client ne reçoit aucune clé de projet Supabase : cette infrastructure reste un détail interne à Orbit.

Ne placez jamais ORBIT_API_KEY dans un navigateur, une application mobile ou de bureau, une variable NEXT_PUBLIC_*, un dépôt, une URL ou des journaux. N’utilisez jamais de clé Supabase publiable, secrète ou service_role comme clé Orbit.

La référence OpenAPI est volontairement en lecture seule : sa copie rendue omet les schémas d’authentification et désactive les contrôles d’essai et de client. Le document complet lisible par machine reste disponible sur /openapi.json. Ne saisissez un identifiant secret Orbit dans aucune page web, y compris la documentation Orbit.

Intégration initiale

Le parcours commercial a été validé sur une Preview contre orbit-dev, avec des comptes confirmés créés par l’opérateur. L’inscription publique reste fermée. Sur un accès de validation, la clé est révélée une seule fois dans le portail et un test Pro via Stripe ne la remplace pas : il modifie seulement le droit et les quotas du même accès. En production, l’intégration reste réservée aux clients approuvés et Orbit fournit par canal sécurisé :

l’environnement et son URL de base ;
une clé Orbit révélée une seule fois ;
les permissions autorisées, actuellement interests:read ;
les quotas minute et jour ;
la date d’expiration éventuelle et la procédure de rotation.

Le client confirme ensuite un appel authentifié sur orbit-dev et conserve le X-Request-Id de ce test de bon fonctionnement. Les clés de production sont distinctes et ne doivent être installées qu’après validation de l’intégration de développement.

Stockage recommandé

Stockez les valeurs dans un gestionnaire de secrets côté serveur et injectez-les à l’exécution :

ORBIT_BASE_URL
ORBIT_API_KEY

Limitez l’accès au seul service appelant Orbit. Masquez les valeurs dans les outils CI, interdisez leur affichage dans les erreurs et ne journalisez jamais les en-têtes de requête.

Rotation et révocation

Un renouvellement utilise une courte période de chevauchement : installez la nouvelle clé, vérifiez-la côté serveur, puis révoquez l’ancienne. En cas de suspicion de fuite, cessez de l’utiliser et demandez sa révocation sans joindre la valeur compromise à un message ou une capture.

Une clé révoquée, expirée, suspendue ou mal formée reçoit 401. Une clé valide sans la permission demandée reçoit 403.

Contraintes d’intégration

Les applications publiques appellent leur propre backend, qui appelle ensuite Orbit. CORS n’est pas une frontière de sécurité et ne transforme jamais une clé embarquée dans un client en secret.

Continuez avec le démarrage rapide ou les erreurs et nouvelles tentatives.