Die Implementierung eines 2 Legged OAuth Provider

Question

Ich versuche, meine Art und Weise um die OAuth-Spezifikation, seine Anforderungen und all Implementierungen ich finden kann, zu finden und, so weit, es scheint wirklich mehr Mühe, als sein Wert, weil ich habe Probleme, eine einzige Ressource, dass Pulls finden sie alle zusammen. Oder vielleicht ist es nur, dass ich bin auf der Suche nach etwas mehr spezialisiert, als die meisten Tutorials.

Ich habe eine Reihe von bestehenden APIs - einige in Java, einige in PHP -, dass ich jetzt brauchen, zu sichern und für eine Reihe von Gründen, scheint OAuth wie der richtige Weg zu gehen. Leider meine Unfähigkeit, die richtigen Ressourcen aufzuspüren mir einen Anbieter erhalten zu helfen und läuft diese Theorie ist eine Herausforderung. das meiste davon Da wird System-zu-System-API-Nutzung sein, ich brauche einen 2-legged-Anbieter zu implementieren. In diesem Sinne ...

1. Kennt jemand gute Tutorials für einen 2-legged OAuth-Anbieter mit PHP zu implementieren?
2. Da ich festlegbar APIs in 2 Sprachen haben, muss ich einen Provider sowohl implementieren, oder gibt es eine Möglichkeit, den Anbieter als „Front-Controller“ zu schaffen, dass ich alle Anfragen durch Trichter können?
3. Wenn PHP-Dienste zu sichern, zum Beispiel muss ich jede API einzeln sichern, indem sie die erforderlichen Ressourcen-Provider auf die jeweils?

Danke für Ihre Hilfe.

Answer 1

Ich möchte einen Schritt zurück und überlegen, was ein richtig authentifizierten Client wird Ihnen schicken.

Können Sie die Schlüssel speichern und Anmeldeinformationen in einer gemeinsamen Datenbank, die von beiden Sätzen von Dienstleistungen zugänglich ist, und implementieren nur den OAuth-Anbieter in einer Sprache? Wenn der Benutzer in einer Anfrage an einen Service (PHP oder Java) sendet überprüfen Sie dann gegen den gemeinsamen Speicher. Wenn der Benutzer den OAuth-Client einrichten wird dann tun Sie all das entweder durch eine PHP oder Java-Anwendung (Ihre Präferenz) und die Anmeldeinformationen in der gemeinsamen DB.

Es gibt einige Oauth Anbieter in anderen Sprachen geschrieben, dass Sie auf einen Blick nehmen mögen:

• PHP - http://term.ie/oauth/example/ (siehe unten Seite)
• Rubin - http://github.com/mojodna/sample-oauth-provider
• http: //blog.bittercoder .com / PermaLink, guid, 0d080a15-b412-48cf-b0d4-e842b25e3813.aspx

Answer 2

Rob, nicht sicher, wo Sie auf diese gelandet, wollte aber meine 2 Cent, falls jemand anderes ran über diese Frage hinzuzufügen.

ich mehr oder weniger hatte die gleiche Frage vor ein paar Monaten und Anhörung über „OAuth“ für den besseren Teil eines Jahres. Ich war ein REST-API Mir Entwicklung benötigt, um zu sichern, damit ich über OAuth begann zu lesen ... und dann zu rollen rückwärts in meinem Kopf meiner Augen beginnen.

Ich habe es wahrscheinlich eine gute und solide Tag oder 2 von Skimming und Lesen, bis ich beschlossen, genauso wie Sie, dass OAuth Müll war verwirrend und gab nur auf ihn.

Also begann ich Möglichkeiten, um sichere APIs im Allgemeinen untersucht, und begann ein besseres Verständnis über die Möglichkeiten zu bekommen, das zu tun. Der beliebteste Weg schien Anfragen an die API zu Senden zusammen mit einer Prüfsumme von die gesamte Nachricht (mit einem geheimen codiert, dass nur Sie und der Server wissen), dass der Server, wenn die Nachricht entscheiden verwenden können es ist Art und Weise manipuliert wurde mit hatte vom Client, etwa so:

1. Client sendet /user.json/123?showFriends=true&showStats=true&checksum=kjDSiuas98SD987ad
2. Server bekommt alles, was, sieht nach oben Benutzer „123“ in der Datenbank, lädt seine geheimen Schlüssel und dann (mit der gleichen Methode der Client verwendet) Wieder berechnet seine eigene Prüfsumme die Anfrage Argumente gegeben.
3. Wenn der Server-generierte Prüfsumme und die gesendeten Prüfsumme des Clients übereinstimmen, die Anforderung ist OK und ausgeführt, wenn nicht, es gilt als manipuliert und abgelehnt.

Die Prüfsumme wird ein HMAC genannt und wenn man ein gutes Beispiel dafür wollen, ist es, was Amazon Web Services verwendet (sie nennen das Argument ‚Signatur‘ nicht ‚Prüfsumme‘ obwohl).

So gegeben, dass eine der Schlüsselkomponenten dieses zu arbeiten ist, dass der Client und Server die HMAC in der gleichen Art und Weise zu erzeugen haben (sonst werden sie nicht zusammenpassen), dort zu sein, Regeln auf, wie alle kombinieren, die Argumente ... dann verstand ich plötzlich alle, dass „natürliche Byte-Reihenfolge der Parameter“ Mist von OAuth ... es war nur die Regeln zu definieren, wie die Signatur zu erzeugen, weil es erforderlich ist.

Ein weiterer Punkt ist, dass jeder param Sie in der HMAC Generation gehören ein Wert ist, dann kann nicht manipuliert werden, wenn Sie die Anfrage senden.

Wenn Sie also nur die URI als Signatur stammt kodieren, zum Beispiel:

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

dann das einzige, was in Ihrer Nachricht, die nicht manipuliert werden kann, ist der URI, alle Argumente können manipuliert werden, da sie nicht Teil der „Prüfsumme“ Wert, dass der Server neu zu berechnen.

Alternativ, auch wenn Sie JEDEN param in der Berechnung enthalten, führen Sie immer noch das Risiko von „Replay-Attacken“, wo ein böswilliger Mann mittleren oder evesdropped kann einen API-Aufruf abfangen und nur halten sie an den Server immer und immer wieder erneut zu senden.

Sie können das Problem beheben, indem ein Zeitstempel hinzugefügt (immer UTC verwenden) in der HMAC Berechnung als auch.

ERINNERUNG: Da der Server die gleiche HMAC berechnen muss, haben Sie entlang einer beliebigen Wertes, den Sie bei der Berechnung außer Ihrem geheimen Schlüssel senden (OAuth nennt es einen consumer_secret glaube ich). Also, wenn Sie Zeitstempel hinzufügen, stellen Sie sicher, dass Sie einen Zeitstempel param zusammen mit Ihrer Anfrage zu senden.

Wenn Sie die API von Replay-Attacken sicher machen möchten, können Sie einen Nonce Wert verwenden können (es ist ein 1-Zeit Gebrauchswert der Server erzeugt, gibt an den Client, der Client in der HMAC verwendet, sendet die Anfrage , die bestätigt Server und markiert dann den Nonce Wert wie im DB „verwendet“ und nie wieder einen Antrag Gebrauch läßt es wieder).

Hinweis: ‚Nonce‘ ist eine wirklich genaue Art und Weise des „Replay-Attacke“ Problem zu lösen - Zeitstempel sind groß, aber weil Computer in-sync-Zeitstempel-Werten nicht immer haben, haben Sie ein akzeptables Fenster auf das ermöglichen, Server-Seite, wie „alt“ ein Wunsch sein könnte (etwa 10 Minuten, 30 Minuten, 1 Stunde .... Amazon nutzt 15 Minuten), bevor wir es annehmen oder ablehnen. In diesem Szenario ist Ihr API während des gesamten Zeitfensters technisch anfällig.

Idenken Nonce Werte groß sind, sollte aber nur müssen in APIs verwendet werden, die kritisch sind sie behalten ihre Integrität. In meinem API, brauchte ich es nicht, aber es wäre trivial später hinzufügen, wenn Benutzer gefordert ... Ich würde buchstäblich nur einen „Nonce“ Tisch in meiner DB hinzufügen muß, setzen Sie eine neue API für Kunden wie:

• /nonce.json

und dann, wenn sie das zurück zu mir in der HMAC Berechnung senden, würde ich braucht die DB zu überprüfen, um sicherzustellen, war es noch nie zuvor und einmal verwendet worden verwendet, es als solches in der DB markieren, so, wenn eine Anfrage kommt HAUPT mit dem gleichen nonce wieder würde ich es ablehnen.

Zusammenfassung

Wie auch immer, auf eine lange Geschichte kurz zu machen, alles, was ich gerade beschrieben ist im Grunde , was als „2-legged OAuth“ bekannt ist. Es ist nicht, dass zusätzliche Schritt der Autorität fließt (Twitter, Facebook, Google, was auch immer), um den Client zu autorisieren, wird dieser Schritt entfernt und stattdessen der Server vertraut implizit den Client, wenn die HMAC ist sie senden übereinstimmen. Das bedeutet hat der Kunde das Recht secret_key und ist es die Nachrichten mit ihm, so der Server vertraut ihn unterzeichnen.

Wenn Sie anfangen, um Online-Suche, scheint diese API-Methoden die bevorzugte Methode, um für die Sicherung nun adays, oder so ähnlich. Amazon fast genau verwendet diese Methode, außer daß sie eine etwas andere Kombinationsverfahren für die Parameter verwenden, bevor das Ganze Unterzeichnung des HMAC zu erzeugen.

Wenn Sie interessiert sind, ich schrieb diese ganze Reise an und durchdachter Prozess, wie ich es lernte. Das könnte helfen eine geführte Tour Denken dieses Prozesses liefern.