Création d’une API pour les applications mobiles - authentification et autorisation

Question

Vue d'ensemble

Je cherche à créer un (ou de REPOS) de l'API pour mon application. La première/le but principal sera pour la consommation par les applications mobiles (iPhone, Android, Symbian, etc). J'ai été à la recherche dans les différents mécanismes d'authentification et d'autorisation pour les Api web (par l'étude d'autres implémentations). J'ai la tête enroulée autour de la plupart des concepts fondamentaux, mais je suis toujours à la recherche de conseils dans quelques domaines. La dernière chose que je veux faire est de réinventer la roue, mais je n'ai pas trouver de solutions standard qui correspond à mes critères (mais mes critères de mon être erronée, alors n'hésitez pas à la critique en tant que bien). En outre, je tiens à l'API d'être la même pour toutes les plates-formes/applications de la consommer.

oAuth

Je vais aller de l'avant et de jeter mon objection à oAuth depuis que je sais qui va probablement être la première solution proposée. Pour les applications mobiles (ou plus précisément d'applications non web), il semble tout simplement mauvais pour quitter l'application (pour aller à un navigateur web) pour l'authentification. En outre, il n'existe aucun moyen (à ma connaissance) pour le navigateur pour revenir à la fonction de rappel pour l'application (en particulier croix-plate-forme). Je connais un couple d'applications pour le faire, mais il se sent juste mal et donne une pause dans l'application UX.

Exigences

1. Utilisateur entre le nom d'utilisateur/mot de passe dans l'application.
2. Tous les appels de l'API est identifié par l'application appelante.
3. Les frais généraux sont réduits au minimum et la auth aspect est intuitive pour les développeurs.
4. Le mécanisme est sécurisé pour l'utilisateur final (leurs identifiants de connexion ne sont pas exposées) ainsi que le développeur (leur demande les informations d'identification ne sont pas exposées).
5. Si possible, ne pas exiger https (pas dur).

Mes Pensées Actuelles sur la mise en Œuvre

Un développeur externe d'une demande d'API compte. Ils recevront un apikey et apisecret. Chaque demande nécessite au minimum trois paramètres.

• apikey - développeur à regisration
• timestamp - doubles comme un identificateur unique pour chaque message pour une apikey
• de hachage hachage de l'horodatage + le apisecret

Le apikey est nécessaire pour identifier la demande publication de la demande. L'horodatage agit de même pour la oauth_nonce et évite ou atténue les attaques de relecture. Le hachage garantit que la demande a effectivement été délivré à partir de la propriétaire de l'apikey.

Pour les requêtes authentifiées (ceux effectués sur le compte d'un utilisateur), je suis encore indécis entre aller avec un access_token route ou d'un nom d'utilisateur et le mot de passe de hachage combo. De toute façon, à un certain point, un nom d'utilisateur/mot de passe combo sera nécessaire. Alors, quand il n', un hachage de plusieurs éléments d'information (apikey, apisecret, timestamp) + le mot de passe serait utilisé. J'aimerais des commentaires sur cet aspect. Pour info, ils auraient à hacher le mot de passe en premier, car je n'ai pas stocker les mots de passe dans mon système sans hachage.

Conclusion

Pour info, ce n'est pas une demande de façon à développer la structure de l'API, en règle générale, la façon de gérer l'authentification et l'autorisation de exclusivement au sein d'une application.

Random Thoughts/Bonus De Questions

Pour les Api qui n'exigent qu'un apikey dans le cadre de la demande, comment empêcher quelqu'un d'autre que le apikey propriétaire d'être capable de voir la apikey (depuis envoyées en clair) et de faire trop de demandes pour les pousser au fond des limites d'utilisation? Peut-être que je suis juste sur la pensée, mais ne devrait pas il y avoir quelque chose pour s'authentifier qu'une demande a été vérifiée pour la apikey propriétaire? Dans mon cas, c'était le but de la apisecret, il n'est jamais affichés ou transmis sans être haché.

En parlant de hachages, qu'en md5 vs hmac-sha1? Est-il vraiment important lorsque toutes les valeurs sont hachés avec suffisamment de temps les données (ie. apisecret)?

J'avais déjà été compte tenu de l'ajout d'un utilisateur/ligne de sel à mon mot de passe des utilisateurs de hachage. Si je devais faire, comment pourrait-il être en mesure de créer un condensé correspondant sans le savoir le sel utilisé?

Answer 1

La façon dont je suis en train de réfléchir à faire la connexion de la partie de cette dans mes projets:

1. avant la connexion, l'utilisateur demande un login_token à partir du serveur. Celles-ci sont générées et stockées sur le serveur, sur demande, et sans doute ont une durée de vie limitée.

2. pour la connexion, l'application calcule le hachage du mot de passe des utilisateurs, hache ensuite le mot de passe avec le login_token pour obtenir une valeur, ils retournent ensuite à la fois la login_token et le hachage.

3. Le serveur vérifie la login_token est ce qu'il a généré, à le retirer de sa liste de validité login_tokens. Ensuite, le serveur combine ses stockées hachage du mot de passe des utilisateurs avec le login_token et la case qui correspond à l'soumis combiné jeton. Si elle correspond à l'authentification de l'utilisateur.

Les avantages sont que vous n'avez jamais stocker le mot de passe des utilisateurs sur le serveur, le mot de passe n'est jamais transmis en clair, le hachage de mot de passe n'est transmis en clair sur la création de compte ( s'il peut y avoir des façons de contourner cela), et il doit être protégé contre les attaques de relecture comme le login_token est retiré de la DB sur l'utilisation.

Answer 2

C'est un ensemble beaucoup de questions en une seule, je suppose que pas mal de gens n'ont pas réussi à lire tout le chemin à la fin :)

Mon expérience de service web d'authentification est que d'habitude les gens overengineer, et les problèmes sont les mêmes que vous rencontrez sur une page web. Possible très simple options pourraient inclure https pour l'étape de connexion, de retour d'un jeton, l'obligeant à être inclus avec la demande future. Vous pouvez également utiliser l'authentification http de base, et juste passer des trucs dans la tête. Pour plus de sécurité, rotation/expire le jetons fréquemment, vérifiez les demandes sont à venir à partir de la même adresse IP bloc (ce qui peut être gênant si comme utilisateurs mobiles de se déplacer entre les cellules), à combiner avec la clé API ou similaire. Sinon, faire de la "demande la clé de" l'étape de l'authentification oauth (quelqu'un l'a suggéré dans une réponse précédente déjà, et c'est une bonne idée) avant l'authentification de l'utilisateur, et de l'utiliser comme une clé requise pour générer le jeton d'accès.

Une alternative que je n'ai pas encore utilisé mais j'en ai beaucoup entendu parler du dispositif de solution respectueuse de l'environnement oAuth est xAuth. Avoir un coup d'oeil et si vous l'utiliser, alors je serais vraiment intéressé à entendre ce que vos impressions sont.

Pour le hachage sha1 est un peu mieux mais ne pas se raccroche à ce sujet - quel que soit l'appareil peut facilement (et rapidement dans une performance de sens) mettre en œuvre est probablement pas un problème.

Espérons que cette aide, bonne chance :)

Answer 3

Donc, ce que vous êtes après est une sorte de mécanisme d'authentification côté serveur qui va gérer l'authentification et l'autorisation des aspects d'une application mobile?

En supposant que c'est le cas, alors je dirais comme suit (mais seulement parce que je suis un développeur Java donc un C# guy ferais autrement):

Le repos de l'authentification et de l'autorisation du service

1. Cela fonctionne uniquement avec le protocole HTTPS pour éviter les indiscrétions.
2. Il sera basé sur une combinaison de RESTEasy, de Printemps, de la Sécurité et de la SAE (pour la connexion unique à travers de multiples applications).
3. Il fonctionne avec les navigateurs internet ou d'applications client
4. Il y aura un compte sur le web interface de gestion pour permettre aux utilisateurs de modifier leurs coordonnées, et les admins (pour certaines applications) pour modifier les niveaux d'autorisation

Le côté client de la sécurité de la bibliothèque/application

1. Pour chaque plate-forme (par ex. Symbian, Android, iOS, etc) créer un adapté de la mise en œuvre de la la sécurité dans la bibliothèque native la langue de la plate-forme (par exemple, Java, ObjectiveC, C, etc)
2. La bibliothèque il doit gérer la demande HTTPS la formation à l'aide de l'Api disponibles pour la plate-forme donnée (par exemple, Java utilise URLConnection etc)
3. Les consommateurs de l'authentification générale et l'autorisation de la bibliothèque (parce que il est tout d') code spécifique interface et ne sera pas heureux si elle ne change jamais donc, assurez-vous qu'il est très flexible. Suivez conception existante choix tels que le Printemps de Sécurité.

Alors, maintenant que la vue à partir de 30 000 pieds est terminée, comment allez-vous faire? Eh bien, il n'est pas difficile de créer une authentification et d'autorisation système basé sur les technologies côté serveur avec un navigateur client. En combinaison avec le protocole HTTPS, les cadres de fournir un processus sécurisé dans un même jeton (généralement présentée sous la forme d'un cookie) générés par le processus d'authentification et utilisé chaque fois que l'utilisateur souhaite faire quelque chose. Ce jeton est présenté par le client au serveur chaque fois qu'une demande a lieu.

Dans le cas de la section locale de l'application mobile, il semble que vous êtes après, une solution qui effectue les opérations suivantes:

1. Application Client a défini une Liste de Contrôle d'Accès (ACL) le contrôle de l'exécution d'accès pour les appels de méthode. Par exemple, un utilisateur peut lire une collection à partir d'une méthode, mais leur ACL permet uniquement l'accès à des objets qui ont un Q en leur nom, de sorte que certaines données de la collection est quiety tiré par la sécurité de l'intercepteur. En Java, c'est simple, il vous suffit d'utiliser le Ressort de la Sécurité des annotations sur le code d'appel et de mettre en œuvre un adapté ACL processus de réponse. Dans d'autres langues, vous êtes sur votre propre et vous aurez probablement besoin d'offrir standard de sécurité le code qui appelle à la sécurité de votre bibliothèque. Si la langue prend en charge l'AOP (Aspect Oriented Programming) puis l'utiliser au maximum de cette situation.
2. La bibliothèque sur la sécurité des caches la liste complète des autorisations en il est privé de la mémoire de l'application en cours, afin de ne pas avoir à rester connecté. En fonction de la durée de la session de connexion, cela pourrait être une opération ponctuelle, qui n'est jamais répété.

Quoi que vous fassiez, ne pas essayer d'inventer votre propre protocole de sécurité, ou de l'utilisation de la sécurité par l'obscurité. Vous ne serez jamais capable d'écrire un meilleur algorithme pour ce que ceux qui sont actuellement disponibles et gratuit. Aussi, la confiance des gens bien connus des algorithmes. Donc, si vous dites que la sécurité de votre bibliothèque donne l'autorisation et l'authentification locale des applications mobiles en utilisant une combinaison de SSL, HTTPS, SpringSecurity et crypté AES jetons, alors vous allez immédiatement creditibility sur le marché.

Espérons que cela aide, et bonne chance avec votre entreprise. Si vous souhaitez plus d'info, laissez-moi savoir j'ai écrit quelques applications web basées sur la Sécurité Printemps, Acl et la comme.

Answer 4

Twitter adressé à l'application externe question dans oAuth, en soutenant une variante qu'ils appellent xAuth. Malheureusement il y a déjà une pléthore d'autres programmes de ce nom, de sorte qu'il peut être source de confusion pour les trier.

Le protocole est le protocole oAuth, sauf qu'il ignore le jeton de demande de phase et simplement émet un jeton d'accès de la paire lors de la réception d'un nom d'utilisateur et mot de passe. (À partir de l'étape E ici.) Cette initiale de la demande et de la réponse doit être assurée - c'est l'envoi du nom d'utilisateur et le mot de passe en clair dans le texte et de récupérer le jeton d'accès et jeton secret. Une fois le jeton d'accès de la paire a été configuré, si la première jeton d'échange a été via oAuth modèle ou de la xAuth modèle n'est pas pertinent à la fois le client et le serveur pour le reste de la session. Ceci a l'avantage que vous pouvez exploiter les oAuth infrastructure et d'avoir de très près la même application pour mobile/web/applications de bureau. Le principal inconvénient est que l'application est accordé l'accès du client nom d'utilisateur et le mot de passe, mais il apparaît comme vos exigences mandat de cette approche.

En tout cas, j'aimerais être d'accord avec votre intuition et de plusieurs autres answerers ici: ne pas essayer de construire quelque chose de nouveau à partir de zéro. Les protocoles de sécurité peut être facile de commencer, mais il est toujours difficile de bien faire, et les plus complexes, ils deviennent de moins en moins probable que vos développeurs tiers pour être en mesure de mettre en œuvre contre eux. Votre hypothétique protocole est très similaire à o(x)Auth - api_key/api_secret, nonce, le hachage sha1 - mais au lieu d'être en mesure d'utiliser l'une des nombreuses bibliothèques existantes à vos développeurs vont avoir besoin de rouler leur propre.