La mise en œuvre d'un 2 fournisseur OAuth en trois étapes

Question

Je suis en train de trouver mon chemin autour de la spécification OAuth, ses exigences et toutes les mises en œuvre que je peux trouver et, jusqu'à présent, il semble vraiment plus de mal que sa valeur parce que je vais avoir du mal à trouver une seule ressource qui tire tous ensemble. Ou peut-être il est juste que je suis à la recherche de quelque chose de plus spécialisé que la plupart des tutoriels.

J'ai un ensemble d'API existantes - certains en Java, certains en PHP - que je dois maintenant sécuriser et, pour un certain nombre de raisons, OAuth semble être la bonne façon de procéder. Malheureusement, mon incapacité à traquer les bonnes ressources pour me aider à obtenir un fournisseur et son lancement est difficile cette théorie. Comme la plupart de ce sera l'utilisation de l'API de système à système, je vais avoir besoin de mettre en œuvre un fournisseur 2 pattes. Dans cet esprit ...

1. Quelqu'un connaît des bons tutoriaux pour la mise en œuvre d'un fournisseur de OAuth 2 pattes avec PHP?
2. Étant donné que je API sécurisables dans 2 langues, dois-je mettre en œuvre un fournisseur dans les deux ou est-il un moyen de créer le fournisseur comme un « contrôleur avant » que je peux passer toutes les demandes par?
3. Lorsque la sécurisation des services PHP, par exemple, dois-je fixer chaque API individuellement en incluant les ressources nécessaires à chaque fournisseur?

Merci pour votre aide.

Answer 1

Je prendrais un peu de recul et de réfléchir à ce qu'un client correctement authentifié va vous faire parvenir.

Pouvez-vous stocker les clés et les informations d'identification dans une base de données commune qui est accessible à partir de deux ensembles de services, et tout mettre en œuvre le fournisseur OAuth dans une langue? Lorsque l'utilisateur envoie une demande à un service (PHP ou Java) vous permet alors de vérifier contre le magasin commun. Lorsque l'utilisateur met en place le client OAuth alors vous faites tout cela soit par une application PHP ou Java (votre préférence), et stocker les informations d'identification dans le DB commun.

Il y a des fournisseurs OAuth écrits dans d'autres langues que vous voudrez peut-être jeter un oeil à:

• PHP - http://term.ie/oauth/example/ (voir en bas de Page)
• Ruby - http://github.com/mojodna/sample-oauth-provider
• http: //blog.bittercoder .com / PermaLink, guid, 0d080a15-b412-48cf-b0d4-e842b25e3813.aspx

Answer 2

Rob, ne savez pas où vous avez atterri sur ce mais je voulais ajouter mes 2 cents au cas où quelqu'un d'autre a couru à travers cette question.

Je plus ou moins eu la même question il y a quelques mois et entendre parler de « OAuth » pour la meilleure partie d'une année. Je développais une API REST je devais assurer donc je commencé à lire sur OAuth ... puis mes yeux ont commencé à rouler en arrière dans ma tête.

J'ai probablement donné une bonne journée solide ou 2 de l'écrémage et la lecture jusqu'à ce que je décide, un peu comme vous, que les ordures OAuth était source de confusion et vient de donner sur le sujet.

Alors je commencé à rechercher des façons de sécuriser les API en général et a commencé à mieux saisir sur les moyens de le faire. La façon la plus populaire semblait envoyer des demandes à l'API ainsi que d'une somme de contrôle de le message entier (codé avec un secret que vous seul et le serveur savoir) que le serveur peut utiliser pour décider si le message avait été falsifié sur son chemin du client, comme suit:

1. Le client envoie /user.json/123?showFriends=true&showStats=true&checksum=kjDSiuas98SD987ad
2. serveur obtient tout cela, regarde utilisateur « 123 » dans la base de données, charge sa clé secrète, puis (en utilisant la même méthode que le client utilisé) recalcule c'est la somme de contrôle PROPRE compte tenu des arguments de requête.
3. Si la somme de contrôle généré et la somme de contrôle de la mise en correspondance envoyé par le client du serveur, la demande est OK et exécutée, sinon, il est considéré comme falsifié et rejeté.

La somme de contrôle est appelé HMAC et si vous voulez un bon exemple de cela, il est ce que Amazon Web Services utilise (ils appellent l'argument « somme de contrôle » « signature » pas bien).

Donc, étant donné que l'un des éléments clés de ce travail est que pour le client et le serveur doivent générer le HMAC de la même façon (sinon ils ne correspondent pas), il doit y avoir des règles sur la façon de combiner toutes les arguments ... alors je compris tout à coup tout ce « naturel ordre des octets des paramètres » merde de OAuth ... il était juste de définir les règles de la façon de générer la signature car elle avait besoin.

Un autre point est que chaque PARAM inclure dans la génération HMAC est une valeur qui ne peut donc pas être trafiqué lorsque vous envoyez la demande.

Donc, si vous encodez simplement la tige URI comme la signature, par exemple:

• /user.json == askJdla9 / kjdas + Askj2l8add

alors la seule chose dans votre message qui ne peut pas être falsifié est l'URI, tous les arguments peuvent réarranger parce qu'ils ne font pas partie de la valeur « contrôle » que le serveur recalculera.

Sinon, même si vous inclure tous les param dans le calcul, vous courez toujours le risque de « attaques replay » où un homme du milieu malveillant ou evesdropped peut intercepter un appel d'API et juste garder réémission au serveur encore et encore.

Vous pouvez résoudre ce problème en ajoutant un horodatage (toujours utiliser UTC) dans le calcul HMAC ainsi.

RAPPEL: Étant donné que le serveur doit calculer la même HMAC, vous devez envoyer le long d'une valeur que vous utilisez dans le calcul SAUF LA CLÉ DE VOTRE SECRET (OAuth appelle un consumer_secret je pense). Donc, si vous ajoutez l'horodatage, assurez-vous d'envoyer un horodatage param avec votre demande.

Si vous voulez faire l'API sécurisée des attaques replay, vous pouvez utiliser une valeur de nonce (il est une valeur d'usage 1 fois le serveur génère, donne au client, le client utilise dans le HMAC, renvoie la demande , le serveur confirme et marque alors que la valeur nonce comme « utilisé » dans le DB et ne laisse jamais une autre demande l'utiliser à nouveau).

NOTE: « nonce » sont un moyen vraiment exact de résoudre le problème « attaque Replay » - horodatages sont grands, mais parce que les ordinateurs ne sont pas toujours des valeurs d'horodatage en-synchronisation, vous devez permettre une fenêtre acceptable sur la côté serveur de la façon dont « ancienne » une demande peut-être (disons 10 minutes, 30 minutes, 1 heure .... Amazon utilise 15min) avant d'accepter ou de le rejeter. Dans ce scénario, l'API est techniquement vulnérable pendant toute la fenêtre de temps.

pense que les valeurs sont grands nonce, mais ne devrait être nécessaire d'utiliser dans les API qui sont essentielles qu'ils gardent leur intégrité. Dans mon API, je ne l'ai pas besoin, mais il serait trivial d'ajouter plus tard si les utilisateurs exigeaient ... Je littéralement juste besoin d'ajouter une table « nonce » dans mon DB, exposer une nouvelle API pour des clients tels que:

• /nonce.json

et puis quand ils nous renverrons à moi dans le calcul HMAC, je besoin de vérifier la DB pour vous assurer qu'il n'a jamais été utilisée avant et une fois utilisé, marquer comme tel dans le DB si une demande est jamais venu à nouveau avec ce même nonce je le rejeter.

Résumé

Quoi qu'il en soit, pour faire une histoire courte, tout ce que je viens de décrire est essentiellement ce qu'on appelle « OAuth 2 pattes ». Il n'y a pas cette étape supplémentaire d'écoulement à l'autorité (Twitter, Facebook, Google, peu importe) d'autoriser le client, cette étape est supprimée et place le serveur fait confiance implicitement le client si le HMAC de leur envoyaient match vers le haut. Cela signifie que le client a le droit secret_key et est la signature de c'est des messages avec elle, de sorte que le serveur fait confiance il.

Si vous commencez à regarder autour en ligne, cela semble être la méthode préférée pour obtenir des méthodes maintenant-de adays, ou quelque chose comme API il. Amazon utilise presque exactement cette méthode, sauf qu'ils utilisent une méthode de combinaison légèrement différente pour leurs paramètres avant de signer le tout pour générer le HMAC.

Si vous êtes intéressé, je rédigea ce voyage ensemble et processus de pensée comme je l'apprendre. Cela pourrait aider à fournir une visite guidée de penser ce processus.