# Stockage du token API

Objectif : l'application locale ne doit pas stocker le token API en clair dans un fichier de configuration.

État actuel du scaffold :

- `--token` : accepté pour test manuel ponctuel ;
- `SYSTEM_UPDATE_TOKEN` : accepté pour développement ;
- trousseau système : prévu, pas encore activé dans `Cargo.toml`.

Identité prévue dans le trousseau :

- service : `system-update` ;
- compte : `api-token`.

Choix technique à finaliser :

- la documentation actuelle de `keyring` indique que Linux dispose de plusieurs magasins possibles, dont keyutils et Secret Service ;
- pour une app GNOME, Secret Service est le choix naturel ;
- l'écosystème `keyring` 4.x sépare davantage les composants de librairie, donc l'ajout Cargo doit être fait après choix précis entre `keyring-core` + store Secret Service ou une version `keyring` 3.x encore centrée librairie.

Références :

- https://docs.rs/keyring/latest/keyring/
- https://docs.rs/crate/keyring/latest
- https://github.com/open-source-cooperative/keyring-rs/wiki/Keyring-Core

Règle de sécurité :

- token jamais loggé ;
- token jamais écrit dans les rapports ;
- token affiché uniquement sous forme de préfixe côté backend ;
- révocation possible côté backend via `api_clients.revoked_at`.