J'irais avec SSL / TLS partout (puisque vous contrôlez les deux côtés, forcer TLS 1.2 devrait être faisable). C'est relativement simple à utiliser et vous bénéficiez de nombreuses fonctionnalités de sécurité gratuitement. Par exemple, si vous n'utilisez pas SSL, vous devrez vous soucier des attaques de relecture.

Si vous êtes préoccupé par les performances, assurez-vous que la reprise de session est prise en charge à la fois par le serveur et le client. Cela rend les poignées de main ultérieures beaucoup moins chères. La prise de contact étant assez chère en SSL par rapport au cryptage des données réelles, cela réduit considérablement la charge globale.

Si vous utilisez HTTP 2, vous pouvez même envoyer plusieurs requêtes via une seule connexion, de cette façon vous éviter la surcharge complète de la négociation TCP et SSL sur les demandes ultérieures.

Je recommande d'utiliser OAuth. Vous devriez certainement le lire si vous ne le connaissez pas. De plus, vous pouvez utiliser des fournisseurs d'identité tiers, afin que vos utilisateurs puissent utiliser leurs comptes Google / Windows Live / etc. pour votre application, en évitant l'enregistrement.

Même si vous souhaitez créer le vôtre cadre d'authentification, je ne recommande pas d'utiliser des sessions qui n'expirent pas. La session devrait expirer après un temps d'inactivité suffisant, sinon cela donne plus de place à l'exploitation (piratage de session par exemple).

Cela dépend du degré de sécurité dont il a besoin . Chaque fois que vous compliquez la solution, vous risquez également de laisser un trou béant . Il est préférable d'utiliser une sorte de module d'autorisation et d'authentification standard de l'industrie.

Tout ira probablement bien, tant que vous:

• cryptez le mot de passe (avec quelque chose comme AES ou Blowfish)
• salage du mot de passe
• envoi des données via HTTPS

Une alternative est OAuth.

Si quelqu'un veut vous pirater assez mal, il trouvera toujours un moyen. Le secret est d'augmenter suffisamment le temps et les efforts nécessaires pour que quelqu'un ne le fasse pas. Par conséquent, si vous ne disposez pas d'énormes quantités de données clients et / ou financières et que vous n'êtes pas une entreprise de premier plan, une mise en œuvre de sécurité standard comme celle ci-dessus devrait convenir.

Dans JEE, nous avons la notion de sécurité gérée par conteneur. Dans ce cas, j'ai configuré mes services de repos pour utiliser l'authentification de base, qui utilise par défaut l'authentification par mot de passe HTTP par rapport à un domaine configuré sur le serveur d'applications. Cela évite le besoin d'un formulaire HTML pour se connecter ou la complexité du déploiement de certificats côté client.

L'application suppose simplement qu'il y aurait un utilisateur principal et peut-être d'autres données telles que les détails d'identification qui sont transmis avec la requête. Cela inclut les API reposantes.

Dans ma configuration, j'ai implémenté un module d'authentification du serveur JASPIC OAuth2 [ Source] qui stocke le jeton OAuth qui est crypté symétriquement là où réside la clé dans le serveur qui a également une durée de vie limitée dans le cookie et utilisez-le comme authentification pour l'application.

En faisant ce qui précède, je garde l'application à l'écart de la sémantique d'authentification et en prime, lorsque je souhaite effectuer des tests d'intégration fonctionnelle avec Selenium, je suis en mesure de revenir à l'utilisation de mots de passe HTTP au lieu d'avoir un test complexe qui se connecte à un fournisseur OAuth tout le temps.

De plus, j'utiliserai toujours SSL pour m'assurer qu'au moins votre transport est sécurisé. Ne pas utiliser SSL ajoute simplement trop de complexité dans la gestion des attaques courantes de votre application.

Rappelez-vous qu'il s'agit de JEE, mais les mécanismes peuvent être appliqués à n'importe quelle technologie.

Vous ne serez jamais sûr à 100% que votre API est sécurisée.

La raison principale en est que vous remettez probablement un binaire à vos clients / utilisateurs qui fonctionne simplement. Ils ont donc tout le temps du monde pour disséquer ce binaire pour y rechercher des clés / secrets, utilisés pour s'authentifier en toute sécurité sur votre serveur API. Le point de terminaison de l'API client est le point le plus faible, car il possède l'appareil sur lequel s'exécute votre binaire, il peut donc manipuler les certificats que son appareil juge valides ou non.

Un exemple clair de ce que je ' Je parle de cet article ("Tutoriel pour la rétro-ingénierie de l'API privée de votre logiciel: pirater votre canapé"). Et je voudrais finaliser cette réponse en citant l'un des derniers paragraphes:

Est-il possible d'empêcher complètement l'utilisation d'une API privée par des clients tiers? Je ne pense pas. L'utilisation de l'épinglage SSL empêcherait de renifler les demandes d'API à l'aide d'une simple technique de proxy transparent comme décrit précédemment. En fin de compte, même si vous obscurcissez le binaire, un hacker motivé avec quelques ressources et du temps sera toujours en mesure de rétroconcevoir le binaire de l'application et d'obtenir la clé privée / le certificat. Je pense que l'hypothèse selon laquelle le point de terminaison du client est sécurisé est intrinsèquement erronée. Un client API est un point faible.

Uniquement HTTPS est un must.

En contrôlant à la fois l'application et l'API, j'implémenterais l'épinglage de certificat. L'épinglage de certificat peut être vaincu mais c'est un bon moyen de dissuasion contre l'inspecteur occasionnel.

Vous pouvez ajouter une autre couche avec Payload Encryption. Cela se fait au prix de la création d'un solide processus de distribution et de rotation des clés.

Si votre application utilise des jetons d'accès ou des cookies de session pour l'autorisation d'API spécifiques, assurez-vous qu'ils expirent. J'observe si souvent des jetons porteurs qui n'expirent pas avant des jours, des mois ou jamais.

Règle d'or: un O / S mobile est un environnement hostile. Traitez-le avec soin & un manque de confiance.

Je pense que ce n'est pas léger et crée plus de charge utile du réseau

Cela a un certain impact sur la latence - donc si vous avez besoin de traiter des données dans l'ordre de 10 secondes de millsecondes, cela peut être une considération. Mais même en 2012, un matériel très basique peut gérer la surcharge de calcul avec un impact négligeable.

qui n'est peut-être pas le mieux adapté pour une application mobile

Ensuite, le ci-dessus n'est pas un problème.