Jetons¶
Les jetons sont destinés aux machines : agents MCP, pipelines CI/CD, Prometheus, scripts d'administration. Les personnes utilisent un compte utilisateur, seul à ouvrir l'interface web, avec les droits de ses groupes (Rôles, groupes et permissions). Il n'existe pas de jeton de lecture ou de triage : pour donner à une personne la lecture ou le triage, ajoutez son compte à un groupe.
Rôles d'un jeton¶
Chaque jeton porte un rôle fixe, qui détermine les endpoints qu'il atteint. Un jeton créé sans
rôle est mcp.
| Rôle | Usage (écran Jetons) | /mcp |
API REST | Changement de statut |
|---|---|---|---|---|
mcp (défaut) |
MCP | ✅ | — (routes de pipeline pour un jeton personnel) | — |
admin |
CLI uniquement | ✅ | ✅ | open, fixed ¹ |
api |
API REST — Swagger et scripts (jetons API) | — | ✅ avec les permissions de son rôle ou de son utilisateur | open, fixed ¹ avec findings.triage |
ci |
Pipeline CI/CD — gate, SARIF, tendance et scans | — | routes de pipeline seulement (/api/v1/ci/), dont les scans qui enregistrent des rapports |
— |
metrics |
CLI seulement | — | /metrics seulement (Prometheus) |
— |
¹ accepted et false_positive exigent une personne connectée à l'interface avec la
permission findings.triage (triage des findings). Sur /mcp, aucun rôle ne
change un statut : les agents ne font que le proposer.
Un jeton mcp peut être restreint à des projets avec --project (répétable) ; un jeton ci
l'est toujours (voir jeton ci et
jetons restreints à un projet). Création,
expiration, renouvellement et révocation en CLI : Jetons Bearer.
Jeton admin¶
Un jeton admin appelle toute l'API REST, par exemple depuis un script d'administration, mais
n'ouvre pas l'interface (la page de connexion ne propose que les comptes) :
security-review-controller token create --label ops-script --role admin
# {"id": "…", "label": "ops-script", "role": "admin", "project": null, "created_at": "…", "token": "UJB7…"}
curl -H "Authorization: Bearer $TOKEN" https://secreview.example.com/api/v1/projects
L'API REST liste les findings d'un projet sur l'ensemble de ses rapports, ouverts par défaut,
du plus grave au moins grave (filtres status, severity et review_type, limit plafonné par
SECREVIEW_MAX_LIST_LIMIT, total donne le nombre de findings correspondants pour paginer).
Sans project, elle liste les findings de tous les projets que lit l'appelant
("project": null) :
curl -H "Authorization: Bearer $TOKEN" \
"https://secreview.example.com/api/v1/findings?project=shop-api&status=open&limit=50"
# {"project": "shop-api", "total": 12, "findings": [{"id": 42, "severity": "critical", "report_id": 7, "project": "shop-api", "branch": "main", "commit_sha": "abc123", "review_type": "codebase-review", "report_created_at": "…", …}, …]}
GET /api/v1/reports liste les rapports (filtres project, risk_level, review_type et
author), chacun avec son author et son submitted_by. L'author n'est renvoyé, filtré,
recherché et trié que pour un appelant qui détient users.manage ou tokens.manage : pour les
autres, il vaut null (dans le rapport et son export Markdown aussi) et le filtre author est
ignoré :
curl -H "Authorization: Bearer $TOKEN" \
"https://secreview.example.com/api/v1/reports?project=shop-api&author=alice@example.com"
Révoquez-le avec security-review-controller token revoke ops-script. Chaque changement de
statut est journalisé avec le label du jeton ou du compte :
INFO security_review_mcp.web: Finding 42 set to fixed by ops-script
et écrit dans le journal d'audit
(GET /api/v1/audit, permission audit.read), avec l'acteur token:ops-script ou
user:<nom>.
Jetons API¶
Un jeton api appelle l'API REST, depuis un script ou depuis la documentation Swagger
(/api/docs, bouton Authorize), avec les droits du contrôle d'accès, lus à chaque requête.
Il n'atteint jamais /mcp et n'ouvre jamais l'interface. Il en existe deux sortes :
- Jeton personnel : créé par un utilisateur pour lui-même, avec l'Usage API REST — Swagger et scripts (voir jetons personnels). Il porte les droits actuels du compte, qui viennent de ses groupes : il n'atteint plus rien dès que le compte les perd.
- Jeton de rôle : créé par un administrateur (
tokens.manage) dans l'écran Jetons, avec l'Usage API REST et un Rôle. Il porte les permissions de ce rôle sur ses projets (tous les projets, ou une liste quand le rôle ne détient que des permissions par projet). Un rôle utilisé par un jeton ne peut pas être supprimé.
curl -X POST -H "Authorization: Bearer $SESSION" -H "Content-Type: application/json" \
https://secreview.example.com/api/v1/me/tokens -d '{"label": "swagger", "expires_in_days": 30}'
# {"id": "…", "label": "alice:swagger", "role": "api", "personal": true, "access_role_id": null, …, "token": "Zq3…"}
curl -H "Authorization: Bearer $TOKEN" https://secreview.example.com/api/v1/me
# {"client": "alice:swagger", "role": "api", "permissions": {"reports.read": ["shop-api"]}, …}
Jetons créés depuis l'interface¶
Un jeton ne donne jamais plus que ce que détient son créateur : créer un jeton, changer ses
projets, renouveler son secret ou le révoquer demande reports.read sur tous les projets du
jeton, avant et après un changement de ses projets, et, pour un jeton api de rôle, chaque
permission de son rôle sur ces projets. L'écran Jetons ne liste que les jetons des projets
que l'utilisateur lit.
Jetons personnels¶
Un utilisateur crée ses propres jetons dans Mon compte > Jetons personnels, avec l'un de trois usages :
| Usage | Rôle | Atteint | Exige |
|---|---|---|---|
| API REST — Swagger et scripts | api |
l'API REST, avec les droits du compte | — |
| MCP | mcp |
/mcp et les routes de pipeline, sur les projets que le compte peut lire |
mcp_tokens.create |
| Pipeline CI/CD | ci |
les routes de pipeline seulement, sur les projets que le compte peut lire | mcp_tokens.create |
Tout jeton personnel suit les mêmes règles :
- un au plus par usage par défaut (
SECREVIEW_PERSONAL_TOKENS_PER_USER) : révoquez-le pour en créer un autre ; - label
<utilisateur>:<label>, avec un:qu'aucun autre label de jeton ne peut contenir, et validité bornée parSECREVIEW_TOKEN_MAX_DAYS; - ses droits sont ceux du compte, lus à chaque requête ; il s'arrête tant que le compte doit changer un mot de passe défini par un administrateur, et il est supprimé avec le compte ;
- personne ne peut le renouveler ni changer ses projets ; un administrateur peut le révoquer depuis l'écran Jetons.
Jetons MCP et CI personnels¶
Un jeton mcp personnel connecte l'agent MCP de l'utilisateur. Il n'est proposé que quand les
groupes du compte portent mcp_tokens.create (rôle mcp-user, voir
Rôles ; 403 sans elle) ; un jeton déjà créé continue de
fonctionner quand le compte la perd, et un administrateur le révoque au besoin. Il atteint les
projets que le compte peut lire (reports.read de ses groupes) : tous les projets quand l'un de
ses groupes lit tous les projets, aucun quand il n'en a pas. La colonne Projets les affiche,
de même que l'écran Jetons pour les administrateurs.
Pour un projet qu'il n'atteint pas, un administrateur donne au compte l'accès au projet (un
groupe qui le lit), ou l'utilisateur le crée depuis Projets s'il est nouveau et qu'il porte
projects.create (voir Création d'un projet) ;
un projet demandé par un enrôlement
attend sa validation. Quand le serveur refuse le jeton (inconnu, révoqué ou expiré), l'agent
reçoit un 401 qui invite l'utilisateur à se reconnecter pour en créer un nouveau.
Un jeton mcp personnel vaut aussi jeton ci personnel sur les routes de pipeline : un seul
SECREVIEW_TOKEN sur le poste sert à la fois à l'agent MCP et à
security-review-ci. Un jeton ci personnel ne sert qu'à séparer les deux
usages ; il n'atteint jamais /mcp. Un rapport enregistré par l'un ou l'autre est soumis par le
jeton (alice:laptop), et son utilisateur en est l'auteur (voir
scan depuis un poste de travail).
Un jeton mcp créé par un administrateur sur l'écran Jetons reste un jeton d'agent MCP
seulement.
curl -X POST -H "Authorization: Bearer $SESSION" -H "Content-Type: application/json" \
https://secreview.example.com/api/v1/me/tokens -d '{"label": "laptop", "role": "mcp"}'
# {"id": "…", "label": "alice:laptop", "role": "mcp", "personal": true, …, "token": "Zq3…"}
curl -X POST -H "Authorization: Bearer $SESSION" -H "Content-Type: application/json" \
https://secreview.example.com/api/v1/me/tokens -d '{"label": "laptop", "role": "ci"}'
# {"id": "…", "label": "alice:laptop", "role": "ci", "personal": true, …, "token": "Zq3…"}