Authentification des demandes de l'application mobile (iPhone) vers l'API Web ASP.Net (Commentaires demandés sur ma conception)
Je conçois un site Web qui aura un compagnon mobile (initialement iPhone uniquement). Le site Web sera une application ASP.Net MVC 3. J'aurai également un site d'API Web ASP.Net (MVC 4) pour exposer les services à l'application iPhone. L'application iPhone aura son propre formulaire pour capturer le nom d'utilisateur et le mot de passe de l'utilisateur et les envoyer à l'API Web dans les en-têtes JSON.
Je veux considérer la sécurité dès le départ plutôt qu'une réflexion après coup. Je ne suis en aucun cas un expert en sécurité. J'ai fait beaucoup de recherches pour voir comment les autres gèrent l'authentification d'un client d'application mobile à partir d'un service Web. Je pense que j'ai trouvé une solution décente qui n'implique pas de se connecter à des oAuths tiers.
J'apprécierais grandement toutes les opinions, conseils, critiques et WTF généraux que chacun d'entre vous peut offrir. :)
Mes plus grandes préoccupations sont:
- S'assurer que les appels passés à l'API Web sont autorisés
- Minimiser le risque d'attaques de rejeu (d'où des horodatages dans les appels ci-dessous)
L'application iPhone sera développée comme telle:
Deux chaînes sont codées en dur dans l'application iPhone (mêmes valeurs pour chaque utilisateur):
- ID d'application
Il s'agit d'une chaîne utilisée pour identifier le type de client qui accède à l'API Web (iPhone, Android, Windows phone, etc.). - Sel de hachage de l'application
Il s'agit d'une chaîne utilisée pour saler les hachages pour les requêtes indépendantes de l'utilisateur.
Deux chaînes sont stockées dans la base de données locale de l'application iPhone (valeurs propres à chaque utilisateur):
- Jeton d'accès utilisateur API
Il s'agit d'une chaîne (jeton) fournie au client par l'API Web lors de l'authentification réussie et permet au client d'accéder à l'API Web sans envoyer le nom d'utilisateur et le mot de passe à chaque demande. - Sel de hachage de l'utilisateur
Il s'agit d'une chaîne qui sert à saler les hachages pour les demandes effectuées sur des comptes d'utilisateurs établis.
L'iPhone fera des appels à l'API Web de la manière suivante:
Méthode API: créer un compte
Le client envoie:
- Nouvelles données de compte (nom d'utilisateur, mot de passe, prénom, nom de famille, etc.)
- ID d'application
- Horodatage UTC
- Hash of UTC Timestamp + ID d'application salé avec le sel de hachage de l'application
Retours d'API:
- Sel de hachage pour nouvel utilisateur
L'idée ici est que, lors de la création d'un compte, je peux utiliser le sel codé en dur de l'application, car ce n'est pas un risque de sécurité énorme si ce sel sortait (par décompilation ou par un autre moyen).
.
Méthode API: Obtenir un compte
(Utilisé pour obtenir le sel de hachage de l'utilisateur pour les comptes qui ont été créés sur le site Web mais qui n'ont pas encore été synchronisés sur l'iPhone. Cela se produit lorsqu'un utilisateur tente de se connecter sur l'iPhone et que l'iPhone détecte qu'il a aucun enregistrement pour ce nom d'utilisateur.)
Le client envoie:
- Username
- Mot de passe (haché avec le sel de hachage de l'application)
- ID d'application
- Horodatage UTC
- Hash of UTC Timestamp + ID d'application salé avec le sel de hachage de l'application
Retours d'API:
- Sel de hachage de l'utilisateur existant
Méthode API: connexion (authentification)
Le client envoie:
- Username
- Mot de passe (haché avec le sel de hachage de l'utilisateur)
- ID d'application
- Horodatage UTC
- Hachage de l'horodatage UTC + ID d'application salé avec le sel de hachage de l'utilisateur
Retours d'API:
- Jeton d'accès utilisateur API
Méthode API: toute commande (c.-à-d. Créer un message, mettre à jour un profil, obtenir des messages, etc.)
Le client envoie:
- Données de commande
- Jeton d'accès utilisateur API
- ID d'application
- Horodatage UTC
- Hachage de l'horodatage UTC + ID d'application + jeton d'accès utilisateur API salé avec le sel de hachage de l'utilisateur
Mes suggestions
- Authentification et autorisation. Construisez-le sur 2 serveurs différents (dans certains projets, j'en ai également utilisé 3). Les serveurs proxy inversés sont vraiment bons avec cela. Authentifiez-vous sur un serveur et autorisez-le sur l'autre.
Je pense que c'est l'étape la plus importante qui est nécessaire dans la sécurité mobile qui utilise des API Web.
Encapsulez tout.
Utilisez SSL pour toutes les informations sécurisées. Dans mon cas, je l'utilise pour tout.
Pour votre horodatage, sélectionnez une heure appropriée pour laquelle vous pouvez avoir une autorisation. Ne faites pas cela très court car votre application deviendra lente ou trop longue car les renifleurs réseau peuvent accéder aux paquets.
Si vous voulez une architecture à 3 serveurs Pour vos demandes, vous avez également une clé d'application que vous utilisez pour générer une clé d'accès (à partir du serveur 1). Cette clé d'accès authentifiera vos demandes qui, après une authentification réussie (à partir du serveur 2), vous pouvez utiliser cette clé pour autoriser vos demandes à partir d'un autre serveur (serveur 3)
Les demandes que vous avez mentionnées sont des normes standard. Je ne vois pas vraiment de problème avec ça.
Je l'ai fait en utilisant l'adhésion de base asp.net mvc 4.0/web api. cela peut vous être utile.
Oui, utilisez SSL à coup sûr
https://github.com/aamir-poswal/Mobile-Apps-Authentication-Authorization-ASP.NET-WEB-MVC-4.
Dans VS 2013, vous pouvez utiliser le modèle "Asp MVC SPA Application" pour générer une implémentation fonctionnelle qui génère un porteur de jeton Oauth2 à la connexion et l'autorise pour les appels de contrôleur WebApi à l'aide des attributs [Authorize]. Il utilise Membership et Entity Framework pour stocker les utilisateurs et les hachages localement dans un serveur SQL. Supprimez simplement les parties asp mvc dont vous n'avez pas besoin et conservez la partie Auth pour WebApi. Plus de détails ici: http://msdnrss.thecoderblogs.com/2013/09/understanding-security-features-in-the-spa-template-for-vs2013-rc/