Gestion des utilisateurs (déprécié)

⚠️

Cette page est dépréciée. Elle décrit comment gérer des utilisateurs à l’aide de l’API d’administration. Vous devez désormais mettre en œuvre l’authentification des utilisateurs dans votre backend et les utilisateurs seront créés à la volée lors de la génération du jeton. La documentation est fournie sur la page Authentification des utilisateurs.

Principe

On distingue deux types d’authentification au sein des widgets :

l’authentification aux APIs d’administration qui permet de gérer des utilisateurs et qui nécessite l’utilisation d’une clé fournie par POSOS sous forme d’un fichier .json. Cette clé est strictement secrète.
l’authentification des utilisateurs aux widgets qui est transparente pour l’utilisateur et lors de l’intégration. Elle est réalisée en fournissant une clé spécifique à l’utilisateur lors de l’initialisation du composant des widgets. Il s’agit du paramètre signingKey

Cette page décrit comment créer des utilisateurs et générer leurs clés, à partir de votre clé éditeur.

Accès à l’API d’administration

URL d’accès

L’API d’administration se trouve à l’adresse suivante :

https://widgets-api.preprod.trusted.posos.co/api/v1/admin

Authentification

L’API est protégée par une authentification par jeton d’accès qui nécessite 2 éléments :

la clé secrète (format .json)
un identifiant Client ID transmis en même temps que la clé et qui peut être retrouvé ci-dessous par environnement :

Client ID

20286154155-852pf0ti456nd81ongbiecmjqgag84q3.apps.googleusercontent.com

La procédure d’authentification est celle décrite dans la page Authentification.

APIs d’administration des utilisateurs

Création d’un utilisateur

La création d’un compte utilisateur nécessite d’envoyer le paramètre externalId du compte à créer. Cet identifiant doit être connu de l’application hôte du widget pour identifier uniquement l’utilisateur. La réponse de l’API contiendra la clé à utiliser pour initialiser le widget pour cet utilisateur (paramètre signingKey), qui devra donc lui être rattachée pour être disponible dans l’application hôte. La documentation complète de l’endpoint peut être lue sur le Swagger de l’API.

Exemple de requête :

Request

POST

/api/v1/admin/user

curl --request POST \
 --url https://widgets-api.preprod.trusted.posos.co/api/v1/admin/user \
 --header 'Authorization: Bearer <token>' \
 --header 'Content-Type: application/json' \
 --data '{
    "externalId": "abcde1234",
}'

Exemple de réponse :

{
  "id": "vFYxK3h2Fn1xUZR4ZyHV2",
  "externalId": "abcde1234",
  "externalSystem": "editor-slug",
  "publicKey": "LS0tLS1CRUdJTiBQVUJMSUMgS0VZLS0tLS0KTUNvd0JRWURLMlZ3QXlFQTNnbU11MUVvdWdaaC9zekZCY0cwQXhjWWM2a2R0aEJTV2J5TmZTUzc0QW89Ci0tLS0tRU5EIFBVQkxJQyBLRVktLS0tLQo=",
  "privateKey": "LS0tLS1CRUdJTiBQUklWQVRFIEtFWS0tLS0tCk1DNENBUUF3QlFZREsyVndCQ0lFSURsUmVtbG9IQUVYYmZIbmRPcmxsSzk4dG44WGdtVXR6QkRraUppRS9xeUkKLS0tLS1FTkQgUFJJVkFURSBLRVktLS0tLQo="
}

Le contenu du paramètre privateKey dans le retour est à sauvegarder pour l’utilisateur et à reporter dans l’initialisation du widget pour celui-ci dans le paramètre signingKey.

Note : le serveur API ne sauvegarde pas cette clé privée, il ne sauvegarde que la clé publique pour pouvoir vérifier les jetons d’authentification.

Regénération des clés

Un endpoint permet de regénérer des clés pour un utilisateur si celle-ci ont été perdues. La documentation complète de l’endpoint peut être lue sur le Swagger de l’API.

Request

PUT

/api/v1/admin/user/:externalId/key

curl --request PUT \
 --url https://widgets-api.preprod.trusted.posos.co/api/v1/admin/user/abcde1234/key \
 --header 'Authorization: Bearer <token>' \
 --header 'Content-Type: application/json' \

Exemple de réponse :

{
  "publicKey": "LS0tLS1CRUdJTiBQVUJMSUMgS0VZLS0tLS0KTUNvd0JRWURLMlZ3QXlFQTNnbU11MUVvdWdaaC9zekZCY0cwQXhjWWM2a2R0aEJTV2J5TmZTUzc0QW89Ci0tLS0tRU5EIFBVQkxJQyBLRVktLS0tLQo=",
  "privateKey": "LS0tLS1CRUdJTiBQUklWQVRFIEtFWS0tLS0tCk1DNENBUUF3QlFZREsyVndCQ0lFSURsUmVtbG9IQUVYYmZIbmRPcmxsSzk4dG44WGdtVXR6QkRraUppRS9xeUkKLS0tLS1FTkQgUFJJVkFURSBLRVktLS0tLQo="
}

Attention : la regénération des clés invalide la clé déjà existante pour l’utilisateur.

Authentification utilisateur FAQ