From cfe4d8b104a0b5b10b8390a4b8c1c442826281bc Mon Sep 17 00:00:00 2001
From: Teddy Roncin <teddy.roncin@proton.me>
Date: Fri, 1 Nov 2024 01:11:18 +0100
Subject: [PATCH] fix: improved docs

---
 docs/doc_developers/api/permissions.md | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/docs/doc_developers/api/permissions.md b/docs/doc_developers/api/permissions.md
index 5af408e..efaa574 100644
--- a/docs/doc_developers/api/permissions.md
+++ b/docs/doc_developers/api/permissions.md
@@ -108,3 +108,13 @@ Pour un utilisateur, on passe par le CAS de l'UTT, avec la route `POST /auth/sig
 Pour une application, on génère un token pour la _clé API_ demandée, puis on retourne le _bearer token_ associé. Il faut aussi bien sauvegarder la date de dernière mise à jour (`tokenUpdatedAt`), et utiliser cette date pour toujours retourner la même version du token (champ `iat` dans l'objet à encoder avec JWT).
 
 L'utilisateur peut renouveler les token de ses `ApiKey`. Le token sera alors modifié, pour empêcher l'accès avec l'ancien token.
+
+## Grant
+
+### Soft grant
+
+N'importe quelle application peut se _soft grant_ une _permission_.
+
+Pour permettre à un utilisateur d'accepter cette _soft grant_, l'_application_ doit rediriger l'utilisateur vers une route sur le front{sup}`route à déterminer`, en lui passant en paramètre l'id de l'_application_, l'URL de redirection, et les IDs des `ApiKeyPermission` pour nécessaires à _l'application_{sup}`noms des arguments à déterminer`.
+
+L'utilisateur sera alors invité à se connecter, à accepter ou refuser les différentes _permissions_, et sera redirigé vers l'URL, avec en paramètre les _permissions_ acceptées{sup}`format à déterminer`.