Sécuriser la vente d'un service informatique

[Cliffe]

Bonjour,

je cherche à sécuriser la vente d'un service informatique.



Sur ce schéma je suis (L), les utilisateurs du service (C1, C2, ...) font des demandes au travers de (P).
Je vends mon service directement à (P) en fonction du nombre d'utilisateur qu'il possède (3 sur mon exemple). Il doit donc m'acheter un abonnement pour 3 utilisateurs.

Évidement il pourrait se contenter de m'acheter un abonnement pour un seul utilisateur ... et c'est là que je cherche un moyen de sécuriser la vente de mon service.

Les utilisateurs (C1, C2, ...) sont sur une plateforme web hébergée par (P). Le token fourni aux utilisateurs permettra d'établir une connexion websocket directe vers la plateforme (L).

Je cherche donc un moyen de m'assurer que (P) ne puisse pas tricher.

[fatal_error]

slt,

une connexion websocket directe

tu peux alors authentifier le client toi même (info client (e.g ip) + token):
tu geres un lookup pour rejeter la connexion si le token est déjà utilisé par un autre client

[Cliffe]

slt,

une connexion websocket directe

tu peux alors authentifier le client toi même (info client (e.g ip) + token):
tu geres un lookup pour rejeter la connexion si le token est déjà utilisé par un autre client

non ça ne répond pas à ma problématique.
L'utilisateur peut être sur n'importe quelle ip.
Par contre il est connecté sur la plateforme (P) avec login/mdp.



En réalité je pense qu'il n'y a pas de solution

[fatal_error]

pe creuse un peu plus.

pour une IP donnée, si tu (L) réponds à cette ip, l'utilisateur ne recevra la réponse que si l'ip est valide.
Sinon il ne recevra rien (packets perdus dans la nature)

Tu peux (de manière tres bebete) appliquer le même principe qu'un ssh auquel tu couples coté (L) le token

Tu peux de manière plus fine (mais l'idée reste la même: appliquer un mécanisme transformant le token en qqch d'unique) retourner un refreshToken de (L) vers (P) (à usage unique)
Lorsque l'utilisateur parle à (L), il fournit le refreshToken. Tu ne lui retournes un accessToken QUE si ce refreshToken n'a jamais été utilisé (accessToken qu'il utilise par la suite pour les connexions ultérieures)

[Cliffe]

Peut être je m'explique pas bien.

Par utilisateur, j'entends la personne qui utilise le site web, et non pas l'ordinateur avec une ip.
Un utilisateur peut donc changer d'ip plusieurs fois par jour, ce n'est pas un problème.


Tu peux imaginer mon service comme l'api google map.
Je souhaite la vendre à P (qui dispose d'une base de donnée d'utilisateurs qui ont accès à son site web, via login/mdp).
P devra me payer en fonction du nombre d'utilisateur qui utilisera mon service.

J'ai pensé à envoyer des sms de confirmation à chaque utilisateur, pour chaque demande de token. Pour cela il faudrait garantir le numéro et l'identité de la personne ... impossible