HTTPS-BACKEND

📋 Vue d'ensemble

L'interface HTTPS-BACKEND représente la somme des interfaces des échanges entre les différents éléments et le Backend :

📱 Application web
☁️ AWS
🔧 Scripts opérateur de production

Les échanges sont basés sur le modèle client/serveur.

Les clients envoient des requêtes au BACKEND qui retourne des fichiers ou des messages d'erreur ou de succès. Le langage de ces messages est, sauf précision contraire, du JSON.

🏗️ Architecture

Backend (Serveur)

L'APP WEB intègre les bundles Symfony suivants :

Bundle	Description
FriendsOfSymfony/FOSOAuthServerBundle	Implémentation d'OAuth 2.0 dans Symfony
FriendsOfSymfony/FOSRestBundle	Bundle Symfony permettant la création d'API REST

🔒 Sécurité de l'interface

Chiffrement

La sécurité employée par l'interface HTTP respecte les normes :

TLS v1.2
TLS v1.3

Modes d'autorisation

Trois modes d'autorisation sont mis en place :

1. Mode Anonyme

Permet d'exécuter des requêtes sans authentification.

2. Mode Utilisateur

Permet d'exécuter des requêtes nécessitant une authentification utilisateur.

Protocole : OAuth 2.0 en mode Password Flow
Concernés : Applications mobiles

3. Mode Client

Permet d'exécuter des requêtes nécessitant une authentification non-rattachée à un utilisateur.

Protocole : OAuth 2.0 en mode Client Credentials
Concernés : Utilisateurs de l'API externe de Tyllt

Tokens OAuth 2.0

Les modes d'autorisation utilisant OAuth 2.0 possèdent un clientId et un clientSecret permettant d'obtenir un token.

Un token est un jeton d'autorisation qui :

✅ Est délivré à un client de confiance authentifié
✅ Permet d'effectuer des actions autorisées sans retransmettre d'identifiants
✅ Contient les droits d'accès du client sur le serveur
✅ Est associé à un rôle utilisateur (niveau de privilèges)
✅ Est associé à un utilisateur dans le cas d'un Password Flow
✅ Possède une date d'expiration
✅ Est présent dans le header des requêtes HTTPS

Authorization: Bearer ACCESS_TOKEN

🗂️ Arborescence des requêtes HTTP

Route	Description
`/api/public/v1/*`	Requêtes ne nécessitant pas d'autorisation
`/oauth/v2/token`	Récupération des tokens (sans autorisation)
`/api/v1/*`	Requêtes nécessitant une autorisation

📡 Requête HTTP

Une requête HTTP est définie par les éléments suivants :

/test/url/{paramChemin}?paramQuery1=value&paramQuery2=value

Composants

Élément	Description
URL	Chemin de la ressource
Méthode HTTP	GET / POST / PUT / DELETE / PATCH
Paramètres d'URL	Chemins dynamiques (ex: `{param1}`)
Paramètres de query	Paramètres optionnels pour filtrage (après le `?`)
Paramètre Body	Objet JSON complet (POST / PUT / PATCH uniquement)
Paramètre Header	Authentification (`Authorization: Bearer token`)

📥 Réponse HTTP

La réponse HTTP est définie par les éléments suivants :

Codes de réponse

Code	Signification
200	✅ Succès de la requête
400	❌ Mauvaise requête (vérifier les données)
401	🔒 Utilisateur non authentifié
403	🚫 Utilisateur n'a pas les droits
404	🔍 Page introuvable
5XX	🔥 Erreur serveur (serveur inaccessible / erreur fatale)

Contenu

Le contenu sera, sauf précision contraire, du JSON.

Gestion des erreurs

Les codes de réponse 5XX / 404 / 403 / 401 / 400 doivent être gérés par les clients, car le traitement de la requête n'aura pas été exécuté.

📋 Vue d'ensemble​

🏗️ Architecture​

Backend (Serveur)​

🔒 Sécurité de l'interface​

Chiffrement​

Modes d'autorisation​

1. Mode Anonyme​

2. Mode Utilisateur​

3. Mode Client​

Tokens OAuth 2.0​

🗂️ Arborescence des requêtes HTTP​

📡 Requête HTTP​

Composants​

📥 Réponse HTTP​

Codes de réponse​

Contenu​

📚 Références​