Information
- OpenAPI version:
3.1.0
Vue d’ensemble
Ce dont un portail d'épargnant a besoin, en valeurs décidées : sa situation, le détail d'un dispositif, ce qui est disponible et pourquoi le reste ne l'est pas, l'historique, l'offre de placement, les documents, le versement volontaire et l'arbitrage.
Les cas d'usage de l'épargnant 0.1.0
Section intitulée « Les cas d'usage de l'épargnant 0.1.0 »Le consommateur est le serveur d’un teneur de compte, jamais le navigateur d’un épargnant. Une page de portail se sert en un à trois appels : le grain est le cas d’usage métier, pas l’écran. La plateforme ne sait jamais qui est devant l’écran du teneur. Elle sait quel client appelle, et pour quelle ressource : l’identifiant d’épargnant que porte un chemin désigne la ressource, il n’est jamais un sujet d’autorisation. Vérifier que la personne connectée est bien le titulaire des avoirs demandés est une obligation du teneur de compte, et une clause du contrat qui le lie à la plateforme. Ce contrat rend des valeurs décidées : la disponibilité, la valorisation et les montants nets sont servis calculés, avec leur motif. Il ne rend jamais les ingrédients dont un portail les recomposerait — ni échéance de lot, ni mesure de conformité, ni paramètre de règle.
La spécification intégrale — chaque opération avec sa description entière — se lit sur la page du contrat.
Authentification
Section intitulée « Authentification »jetonPartenaire
Section intitulée « jetonPartenaire »Le jeton est obtenu par le client credentials grant OAuth 2.0 : l’appelant est le serveur du teneur de compte, pas une personne. Il est validé comme par tout serveur de ressources — signature, émetteur, dates, audience, tenant comparé au tenant du déploiement.
L’audience est celle de ce contrat. Le jeton doit avoir été obtenu pour la surface de l’épargnant : un jeton obtenu pour celle du correspondant est rejeté en 401, et non en 403 — il ne nous était pas adressé, ce n’est pas un droit qui manque. Un client enregistré ne sert qu’un teneur de compte ; il peut en revanche servir les deux surfaces, si son enregistrement l’y autorise. Un teneur qui sert ses deux portails depuis un seul serveur obtient donc deux jetons et route par surface.
Le jeton authentifie, il n’autorise pas : aucune portée, aucun claim propriétaire n’accorde quoi que ce soit. L’autorisation est rendue à chaque appel par le point de décision, sur la question relationnelle « ce client sert-il le teneur dont relève la ressource, et ce cas d’usage est-il dans son périmètre souscrit ? ». La liste de portées de ce schéma est vide, et c’est intentionnel.
Security scheme type: http
Bearer format: JWT