Aperçu
Je cherche à créer une API (REST) pour mon application. L'objectif initial / principal sera la consommation par les applications mobiles (iPhone, Android, Symbian, etc.). J'ai étudié différents mécanismes d'authentification et d'autorisation pour les API Web (en étudiant d'autres implémentations). J'ai la tête tournée vers 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 ne trouve aucune solution standard qui corresponde à mes critères (cependant mes critères peuvent être erronés, alors n'hésitez pas à critiquer cela aussi). De plus, je souhaite que l'API soit la même pour toutes les plates-formes / applications qui la consomment.
oAuth
Je vais aller de l'avant et rejeter mon objection à oAuth car je sais que ce sera probablement la première solution proposée. Pour les applications mobiles (ou plus spécifiquement les applications non Web), il semble tout simplement erroné de quitter l'application (pour accéder à un navigateur Web) pour l'authentification. De plus, il n'y a aucun moyen (à ma connaissance) pour le navigateur de renvoyer le rappel à l'application (en particulier multiplateforme). Je connais quelques applications qui font cela, mais cela ne semble pas juste et donne une pause dans l'application UX.
Exigences
- L'utilisateur entre le nom d'utilisateur / mot de passe dans l'application.
- Chaque appel d'API est identifié par l'application appelante.
- Les frais généraux sont réduits au minimum et l'aspect authentification est intuitif pour les développeurs.
- Le mécanisme est sécurisé tant pour l'utilisateur final (ses informations de connexion ne sont pas exposées) que pour le développeur (leurs informations d'identification d'application ne sont pas exposées).
- Si possible, ne pas exiger https (en aucun cas une exigence stricte).
Mes réflexions actuelles sur la mise en œuvre
Un développeur externe demandera un compte API. Ils recevront un apikey et un apisecret. Chaque demande nécessitera au moins trois paramètres.
- apikey - remis au développeur lors de l'enregistrement
- horodatage - sert également d'identifiant unique pour chaque message pour un apikey donné
- hash - un hachage de l'horodatage + l'apisecret
L'apikey est nécessaire pour identifier l'application émettrice de la demande. L'horodatage agit de la même manière que oauth_nonce et évite / atténue les attaques de relecture. Le hachage garantit que la demande a effectivement été émise par le propriétaire de l'apikey donné.
Pour les demandes authentifiées (celles effectuées pour le compte d'un utilisateur), je suis toujours indécis entre une route access_token ou un combo de hachage nom d'utilisateur et mot de passe. Quoi qu'il en soit, à un moment donné, un combo nom d'utilisateur / mot de passe sera requis. Donc, quand c'est le cas, un hachage de plusieurs informations (apikey, apisecret, horodatage) + le mot de passe serait utilisé. J'aimerais avoir des commentaires sur cet aspect. FYI, ils devraient d'abord hacher le mot de passe, car je ne stocke pas les mots de passe dans mon système sans hachage.
Conclusion
Pour info, il ne s'agit pas d'une demande sur la façon de créer / structurer l'API en général, mais uniquement sur la façon de gérer l'authentification et l'autorisation à partir uniquement d'une application.
Pensées aléatoires / questions bonus
Pour les API qui ne nécessitent qu'un apikey dans le cadre de la demande, comment empêcher quelqu'un d'autre que le propriétaire de l'apikey de pouvoir voir l'apikey (depuis envoyé en clair) et faire des demandes excessives pour les pousser au-delà des limites d'utilisation? Peut-être que je réfléchis juste à cela, mais ne devrait-il pas y avoir quelque chose pour authentifier qu'une demande a été vérifiée auprès du propriétaire de l'apikey? Dans mon cas, c'était le but de l'apisecret, il n'est jamais montré / transmis sans être haché.
En parlant de hachage, qu'en est-il de md5 vs hmac-sha1? Est-ce vraiment important que toutes les valeurs soient hachées avec des données suffisamment longues (c.-à-d. Apisecret)?
J'avais déjà envisagé d'ajouter un sel par utilisateur / ligne au hachage de mot de passe de mes utilisateurs. Si je devais faire cela, comment l'application pourrait-elle créer un hachage correspondant sans connaître le sel utilisé?