# API de SSKS

L'URL par défaut de SSKS est ssks.seald.io.

# En-têtes des requêtes

L'authentification se fait par des headers HTTP :

Variable Type Description
X-SEALD-APPID (requis) String Application ID, donné sur le tableau d'administration du Seald SDK
X-SEALD-APIKEY (requis) String Clé d'API, donnée sur le tableau d'administration du Seald SDK
Content-type String application/json

Pour savoir où trouver ces valeurs, référez-vous au paragraphe en question dans le guide concernant l'intégration du 2-man-rule.

# Requêtes

# Envoi d'un challenge

Ce point d'API est appelé par le serveur de l'application utilisant le SDK, et permet de :

  • Créer un "utilisateur" au sens de SSKS (si create_user est à True) ;
  • Créer une "Session" ;
  • Si une identité a déjà été stockée sur SSKS avec cette adresse email, must_authenticate est mis à true ; si non, à false ;
  • Retourner un session_id et must_authenticate ;
  • Si must_authenticate est true, envoyer un challenge par email à l'utilisateur, le backend ne doit pas avoir accès à ce challenge. Le challenge est valable 6h.

Le backend doit renvoyer le session_id et must_authenticate au frontend, tel qu'expliqué dans le guide d'intégration du 2-man-rule sur le backend.

# URL

POST https://{SSKS_URL}/tmr/back/challenge_send/

# Format du corps de la requête

Il s'agit d'une requête POST au format JSON :

Variable Type Description
create_user (default: false) Boolean Si true, créé un utilisateur s'il n'existe pas. Sinon rejette avec une erreur 404. Si inutilisé, l'application doit manuellement créer un utilisateur
user_id (requis) String Identifiant unique de l'utilisateur. Peut être un ID, un UUID, une adresse email. La donnée est stockée en clair sur SSKS.
email (requis) String Adresse e-mail de l'utilisateur. Utilisée pour envoyer le challenge. Elle n'est pas stockée en clair sur SSKS, elle est hachée de sorte de pouvoir vérifier que l'adresse donnée lors d'une utilisation ultérieure est la même.
template (requis) String Template au format HTML de l'email contenant le challenge d'authentification envoyé à l'utilisateur. Doit contenir le String $$CHALLENGE$$ qui sera remplacé par le challenge par SSKS.

# Format de la réponse

Au format JSON :

Variable Type Description
session_id String ID de la session ainsi créée. Doit être transmis au frontend.
must_authenticate Boolean Booléen indiquant si la session créée a besoin d'un challenge. Si true, le serveur envoie un email à l'utilisateur, contenant ce challenge, qu'il devra répéter dans le frontend dans les 6h. Si false, la session peut directement enregistrer son identité sur SSKS sans challenge.

# Création manuelle d'un utilisateur

Ce point d'API peut être utilisé si create_user est à False sur le point d'API précédent. Cela va juste créer un "utilisateur" vierge au sens de SSKS.

# URL

POST https://{SSKS_URL}/tmr/back/create_user/

# Format du corps de la requête

Variable Type Description
user_id (required) String Identifiant unique de l'utilisateur. Peut être un ID, un UUID, une adresse email. La donnée est stockée en clair sur SSKS.
email (required) String Adresse e-mail de l'utilisateur. Utilisée pour envoyer le challenge. Elle n'est pas stockée en clair sur SSKS, elle est hachée de sorte de pouvoir vérifier que l'adresse donnée lors d'une utilisation ultérieure est la même.

# Réponse

Ce point d'API n'a pas d'information à retourner au serveur. Il répond simplement avec {"status": "ok"}.