Channels et authentification
Un channel décrit un échange entre Ormuz et le système partenaire. Le mécanisme et la direction déterminent qui possède le contrat, qui fournit le secret et quelle extrémité doit connaître l’URL de l’autre.
La matrice des quatre channels
| Channel | Initiateur | Contrat de référence | Exemple de rôle |
|---|---|---|---|
api_out | Ormuz | API du partenaire | Ormuz appelle un PSP, une API KYC ou un service de données. |
api_in | Partenaire | API Ormuz | Un ERP ou un système métier appelle une surface Ormuz accordée à l’extension. |
event_in | Partenaire | Événement/webhook du partenaire | Le partenaire pousse à Ormuz un changement survenu dans son système. |
event_out | Ormuz | Événement Ormuz | Ormuz pousse des événements plateforme vers un endpoint du partenaire. |
Une extension peut déclarer les channels dont elle a besoin ; elle n’a pas à couvrir les quatre cases. Le contrat V1 accepte au plus un channel de chaque type par extension.
Qui possède le contrat ?
La règle est simple : le propriétaire du contrat est la source du mécanisme.
- pour une API, le serveur qui héberge l’API définit le contrat ;
- pour un événement, l’émetteur définit le type d’événement et son enveloppe ;
- l’adaptation d’un contrat partenaire vers un objet ou événement Ormuz ne transfère pas automatiquement l’autorité métier.
Secrets et endpoints
| Channel | Secret | URL |
|---|---|---|
api_out | Le partenaire émet le credential qu’Ormuz détient pour appeler son API. | Ormuz connaît l’endpoint partenaire. |
api_in | Ormuz émet le credential accordé à l’extension. | Ormuz expose l’API consommée par le partenaire. |
event_in | Le partenaire fournit le secret nécessaire à la vérification des événements entrants lorsque son contrat l’exige. | Ormuz expose l’endpoint d’ingestion. |
event_out | Ormuz émet le secret qui permet au partenaire de vérifier les événements reçus. | Le partenaire fournit une URL cible à Ormuz. |
Ne copiez jamais un secret émis par Ormuz dans extension.yaml ni dans une autre métadonnée de découverte. Les secrets appartiennent au cycle de vie de la configuration, pas au manifeste public.
Règles par channel
api_in
Déclarez explicitement les permissions minimales nécessaires. Une permission disponible dans la plateforme n’a pas à être demandée si l’intégration ne l’utilise pas.
event_out
Déclarez les types d’événements effectivement livrables et le champ de configuration qui contient l’URL cible. Ce champ doit être une URL, pas une chaîne libre.
event_in
Validez l’authenticité et normalisez l’événement selon le contrat externe avant de l’exposer comme événement d’extension. Un événement entrant n’est pas un droit automatique de muter un objet plateforme.
api_out
Les credentials fournis par le marchand doivent rester confinés au channel concerné. Les options dynamiques dépendant d’un service externe sont rattachées à cette capacité plutôt qu’à un accès générique au réseau.