Authentification
Obtenir un jeton porteur et appeler l'API Cockpit pour le compte d'un tenant.
Jetons porteurs
Chaque requête à l'API de gestion (/api/…) doit inclure un jeton porteur :
Authorization: Bearer <access-token>
Le jeton identifie l'utilisateur, le tenant dans lequel il agit, et les permissions qu'il détient. Les requêtes sans jeton valide reçoivent 401 Unauthorized ; un jeton valide mais dépourvu de la permission requise reçoit 403 Forbidden.
Obtenir un jeton
Se connecter
Authentifiez-vous avec les identifiants de l'utilisateur (et un second facteur si activé) via l'endpoint de connexion du Cockpit. En cas de succès, vous recevez un jeton d'accès et un jeton de rafraîchissement.
Appeler l'API
Envoyez le jeton d'accès dans l'en-tête Authorization à chaque requête.
Rafraîchir
Lorsque le jeton d'accès approche de son expiration, utilisez le jeton de rafraîchissement pour en obtenir un nouveau sans ressaisir les identifiants. Les durées de vie des jetons sont configurées dans les paramètres host.
Pour un accès de machine à machine, utilisez une identité de service configurée par votre administrateur plutôt que les identifiants d'un utilisateur humain.
Sessions et invalidation
Les jetons sont liés à une session. Un jeton cesse d'être accepté lorsque la session est révoquée, que le mot de passe de l'utilisateur change, ou que l'utilisateur se déconnecte — un jeton compromis peut ainsi être coupé de manière centralisée. Les jetons d'accès sont de courte durée ; les jetons de rafraîchissement ont une durée de vie plus longue et sont eux aussi révocables.
Authentification multifacteur et authentification unique
Le Cockpit prend en charge plusieurs méthodes de connexion ; leur disponibilité dépend de la configuration de votre tenant :
| Méthode | Remarques |
|---|---|
| Mot de passe | Avec une politique de mot de passe configurable |
| TOTP (double authentification) | Mots de passe à usage unique basés sur le temps, avec codes de récupération |
| WebAuthn / FIDO2 | Passkeys, clés de sécurité et Windows Hello |
| Authentification unique (SSO) | Azure AD / Entra ID, Okta, Keycloak via votre fournisseur d'identité |
Jetons host vs jetons tenant
La plupart des endpoints opèrent au sein d'un seul tenant. Les endpoints au niveau host (création de tenants, modification de paramètres globaux de la plateforme, gestion des éditions) nécessitent un jeton émis dans le contexte host et la permission host appropriée — voir Administration de la plateforme.
Endpoints de protocole public
Les endpoints de protocole public n'utilisent pas les jetons porteurs du Cockpit. Chacun utilise l'authentification définie par son propre standard — par exemple un jeton Azure AD pour les requêtes de déchiffrement DKE, ou des clés de compte ACME pour l'enrôlement ACME.