Est-ce que tu veux coupler l’auth et le reste de l’app, sont-ce des services séparés et indépendants ? L’auth fait-il la supposition d’une forme de stockage ou est-ce que c’est aussi un service séparé ?

Ensuite, est-ce que tu dev juste pour toi, où tu fais un framework ?

L’archi la plus flexibles serait d’avoir 3 services, un pour l’auth, un pour le stockage, et le reste. Mais ça a un coup niveau perf et en termes de couches d’abstraction à maintenir.

En partant sur du un une session => un compte => une identité, et en supposant qu’il n’y a pas de hiérarchie d’identités, on aura donc au moins une identité centrale qui solidarise tout, et un compte avec un type, et des meta information, et un profile de compte qui lui dépend du type de compte (local, facebook, etc).

On a des identifiants qui font passer par un backend qui va devoir retourner une identité et l’attacher à la session, sachant que la session doit être l’objet central à ce moment. Stocker ou pas la session dépend du besoin d’historique, perso je ne le fais pas.

Si on se sent chaud, on peut rajouter une notion de point de connexion, qui est un intermédiaire entre le l’identité et le compte qui comprend des choses comme des identifiants unique (clé API, etc) ou le moyen de connexion (client, device, url de connexion…), etc. Ca peut être utile si on a une app web qui utilise ce genre d’API. C’est également le point d’entrée des web hook, c’est à dire le point d’entrée des services externes autorisés par le détenteur de l’identité. Dans ce cas, la connexion ordinaire devient une de ces opérations également, et ça rajoute une couche. C’est chiant, mais c’est plus flexible.

Les permissions, pareillement, sont liées à un compte, ou au point de connexion et non à une identité, puisque que ce sont les permissions des actions qu’on peut faire sur ce compte/point de connexion. Le compte local devient donc un service comme les autres.

La session permet juste un accès rapide au compte “local” pour obtenir les permissions et le profile “locaux” avec un cache pour un accès rapide.

La partie la plus compliquée, c’est l’auth, car tout ne se passe pas par une logique identifiants = connection. Et faire un truc générique, c’est très chaud, et ça dépend du nombre de services visés, de leur nature, du degré d’intégration et des phases de la lune.

soit UserA ==> twitter+ fb + compte onsite avec droit spécifiques et infos supp

par exemple qui correspond à la même personne

et pas à 2 comptes différents

Je suppose qu’il faut surclasser le model User avec une classe Identity par exemple

faire des vérifs en base avec un param unique et ajouter s’il existe et register form sinon?

j’ai substitué l’auth de django à celle du serveur ldap de mon entreprise sans trop d’effort via un module dédié.

le framework propose juste un service d’auth par défaut mais qui peut dégager si besoin.