Sécurisation Ressources REST avec Angularjs

Salut,

Quand tu dis que le backend sera développé en "Java", tu parles du langage Java ou du Javascript ? Car ce n'est pas du tout la même chose.
Sinon, pour la sécurisation de l'API, tu peux regarder du côté du protocole OAuth2 (http://www.bubblecode.net/fr/2016/01/22/comprendre-oauth2/).

Merci betaWeb pour ta réponse.
Effectivement, nous allons développé notre backend en langage java.
Y'a t il une différence?

Merci

Beh c'est que si c'était en Javascript j'aurais pu vous aider davantage, alors que là je ne peux rien pour vous je ne m'y connais pas Java.

Ou aussi les JWT

@Emix JWT s'appuie sur le protocole OAuth ;)

Oui je sais, mais oauth peut paraître compliqué, tandis que les JWT sont plutôt simples à comprendre pour commencer.

@Emix Encore une fois : JWT implémente OAuth (qui est un protocole pour rappel), donc il faut comprendre OAuth (et ses subtilités) pour utiliser JWT, sinon ça ne sert à rien puisqu'on ne sait pas ce que l'on fait ;)

Encore une fois d'accord mais lors de l'implémentation oauth peut paraitre une vrai usine à gaz.
Bref,

@Emix C'est sûr qu'il faut un peu se triturer les méninges, mais il y a tellement de ressources sur le net que je pense que ça devrait aller ^^

@betaWeb, as tu un lien pour expliquer le lien entre JWT et OAuth ? Car de ce que j'ai vu, Ils n'implémentent pas le même protocole.

A mon sens, la sécurisation d'une API inclus mais ne se limite pas au système d'authentification. Je vais essayer brièvement ici d'expliquer un peu les principaux points de base à prendre en compte (liste non-exhaustive):

Authentification

Comme discuté plus haut dans le fil de discussion, tu peux utiliser JWT ou OAuth2. A noter ici que JWT est utilisé pour formater/crypter l'information de manière à ce que l'on puisse en vérifier l'intégrité, c'est à dire que les données inclus dans le payload du jWT (généralement les informations liés à l'utilisateur connecté) sont signés et ceci afin d'être certains que l'information échangé n'a pas été altéré. Je t'invite à aller jeter un œil un peu pour voir de quoi on parle réellement https://jwt.io/
A l'inverse, OAuth est un protocole d'autorisation, qui peut s'appuyer (ou pas) sur JWT pour générer ses tokens. Ou je bosse, c'est la solution que nous avons choisi en implémentant un serveur OAuth2 + JWT via lequel toutes nos autres API passent pour l'accès aux ressources protégées.

Dans notre cas OAuth est un choix et en aucun cas une obligation. Tu peux très bien implémenter un système d'authentification basé simplement sur JWT. La transmission du JWT se fait généralement via les en-têtes (Authorization: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ). Le client (application Angular par exemple) envoi le JWT sur chaque requête nécessitant une authentification.
Au niveau de ton API tu pourras du coup, pour chaque accès à une ressource protégé, vérifier ce token et autoriser l'accès ou non.

SSL

Lorsque l'on parle d'API REST, il faut garder à l'esprit que absolument toutes les requêtes doivent être encryptés (https). L'utilisation d'un protocole sécurisé permet de s'assurer que les données transmises n'aient pas été altérés durant le transport de la requête. Sur un protocole standard http, l'envoi par exemple de données sensibles comme un couple login/mot de passe est transmis en clair au serveur. Une attaque très connu appelé Man-in-the-middle (l'homme du milieu) permet de prendre avantage du protocole http en sniffant les communications entre 2 points et éventuellement les altérer ou simplement les récupérer.
Concernant la mise en place, je préconise 2 solutions:

• Pour les serveurs de test/recette: Implémentation du SSL avec Let's Encrypt (gratuit)
• Pour la production, implémentation du SSL via un tier de confiance (Autorité de certification) permettant de jouer un rôle d'authentification et assurer aux utilisateurs que le site sur lequel ils sont est bien celui qu'il prétend être (phishing).

CORS

Chaque navigateur implémente en son cœur une politique dite de same-origin (même origine) afin d'empêcher du code Javascript d'utiliser des ressources présentent sur une origine différente (par exemple, un domaine différent) de celle à partir de laquelle ces ressources ont été dé-servis.
CORS ou Cross-Origin Resource Sharing est une technique permettant d'autoriser du Javascript sur une page web à consommer les ressources d'une API REST dé-servis depuis une origine différente.
Pour faire simple, chaque requête contient dans ses en-têtes une Origin spécifiant l'origine du client depuis lequel la requête a été initiée. Le serveur considérera l'origine de la requête et autorisera ou refusera la demande. Si le serveur autorise la requête, il répondra avec la ressource demandée et inclura dans ses en-têtes l'entrée Access-Control-Allow-Origin. Cet en-tête indique au client quelles origines sont autorisées à accéder à la ressource. Si l'en-tête Access-Control-Allow-Origin correspond à Origin, le navigateur autorisera la requête.
A contrario, si Access-Control-Allow-Origin n'existe pas dans la réponse ou s'il ne correspond pas à Origin, le navigateur annulera la requête.
IMPORTANT: tu trouveras beaucoup d'exemple sur internet ou Access-Control-Allow-Origin a la valeur * (Access-Control-Allow-Origin: *). Ce n'est pas recommandé et dangeureux dans la mesure ou toutes origines sera du coup en mesure d'accèder aux ressources de ton serveur (néanmoins, si une ressource nécessite une authentification utilisateur, elle restera protégée)

Il y a d'autres points à prendre en compte et ça ne me dérange pas d'en discuter ici ou en privé, mais les 3 cités plus haut sont déjà un bon début.