Sichern meiner REST-API mit OAuth bei gleichzeitiger Ermöglichung der Authentifizierung über OAuth-Anbieter von Drittanbietern (mithilfe von DotNetOpenAuth)

Ich habe ein Produkt mit einer einfachen REST-API, sodass Benutzer des Produkts direkt in die Produktfunktionen integriert werden können, ohne meine Webbenutzeroberfläche zu verwenden.

Vor kurzem haben verschiedene Drittanbieter Interesse an der Integration ihrer Desktop-Clients in die API geweckt, damit Benutzer meines Produkts mit dieser Drittanbieteranwendung auf ihre Daten zugreifen können.

Ich habe gesehen, dass Anwendungen, die Twitter verwenden möchten, sich über eine von Twitter gehostete Anmeldeseite authentifizieren, die eine bestimmte Anwendungsberechtigung für den Zugriff auf die Daten dieses Benutzers erteilt. Sie klicken auf die Schaltfläche "Zulassen" oder "Verweigern" und der Authentifizierungsvorgang ist abgeschlossen. Facebook verwendet den gleichen Mechanismus wie ich es am besten beurteilen kann.

Nach weiteren Untersuchungen scheint dies OAuth in Aktion zu sein, und da meine API .NET-basiert ist, denke ich, ich sollte DotNetOpenAuth verwenden und einen ähnlichen Mechanismus bereitstellen. Leider sind die Beispiele (wenn überhaupt) nur spärlich dokumentiert, und die einzigen Tutorials, die ich online finden kann, scheinen darauf ausgerichtet zu sein, Ihnen dabei zu helfen, Ihren Benutzern einen Anmeldemechanismus bereitzustellen, damit sie sich über einen Drittanbieter auf Ihrer Website anmelden können.

Was ich wirklich gerne tun würde, ist, dass meine REST-API die gesamte Kernauthentifizierung und Geschäftslogik für meine Webanwendung übernimmt und dass meine Webanwendung im Wesentlichen eine andere Anwendung ist, die die API nur über OAuth verwendet. Benutzer würden sich auf der Website entweder direkt mit ihrem Benutzernamen und Passwort oder über einen Drittanbieter wie MyOpenID oder Facebook authentifizieren, und dann würde die Website das zurückgegebene Token irgendwie zur Authentifizierung gegen die REST-API verwenden.

Grundsätzlich sieht es so aus, als ob ich meine API brauche, um einen OAuth-Dienst zu hosten, aber auch Benutzer, die einen OAuth-Dienst eines Drittanbieters verwenden. Ich kann nicht anders, als zu glauben, ich habe nicht genug Verständnis für OAuth, um zu entscheiden, ob ich Dinge überkompliziere oder ob das, was ich versuche, eine gute oder schlechte Art ist, Dinge zu tun.

Kann mir jemand zumindest einen umfassenden Überblick über die Schritte geben, die ich unternehmen muss, oder was ich beachten sollte, um dies zu erreichen? Oder zeigen Sie mir einige Tutorials? Oder meinen Vorschlag sprengen und mir sagen, dass ich (architektonisch) alles falsch mache?

Zunächst möchte ich den Unterschied zwischen Authentifizierung und Autorisierung hervorheben:

Ein Benutzer authentifiziert sich bei Ihrer Website, indem er einen Berechtigungsnachweis wie einen Benutzernamen und ein Kennwort angibt. Mit OpenID kann dies verschoben werden, indem der Benutzer sich bei einem anderen Dienst authentifiziert , der dann im Namen des Benutzers die Identität des Benutzers auf Ihrer Website bestätigt. Ihre Site vertraut dem Drittanbieter-Service (dem OpenID-Anbieter) und berücksichtigt daher den angemeldeten Benutzer.

Ein Dienst oder eine Anwendung authentifiziert sich nicht bei Ihrer Website - zumindest normalerweise nicht. Ein Benutzer autorisiert einen Dienst oder eine Anwendung, auf die Daten des Benutzers zuzugreifen. Dies erfolgt normalerweise, indem die Anwendung die Autorisierung des Dienstanbieters anfordert und den Benutzer dann an den Dienstanbieter sendet, wo sich der Benutzer zuerst authentifiziert (damit der Dienstanbieter weiß, mit wem er spricht), und der Benutzer dann zur Site sagt: "Ja, Es ist in Ordnung, wenn [Anwendung] [auf eingeschränkte Weise] auf meine Daten zugreift. " Von da an verwendet die Anwendung ein Autorisierungstokenum auf die Benutzerdaten auf der Site des Dienstanbieters zuzugreifen. Beachten Sie, dass sich die Anwendung nicht als Benutzer authentifiziert, sondern einen anderen Code verwendet, um dem Dienst zu versichern, dass er zum Zugriff auf die Daten eines bestimmten Benutzers berechtigt ist.

Wenn diese Unterscheidung klargestellt ist, können Sie auf Ihrer Website völlig unabhängig Entscheidungen über Authentifizierung und Autorisierung treffen. Wenn Sie beispielsweise möchten, dass sich Ihre Benutzer mit allen Benutzernamen + Kennwort, OpenID und Facebook anmelden können, können Sie dies tun. Eine völlig orthogonale Entscheidung ist, wie Sie Anwendungen autorisieren (es gibt viele Protokolle, die Sie dafür verwenden können, wobei OAuth natürlich sehr beliebt ist).

OpenID ist auf Benutzer fokussiert Authentifizierung . OAuth konzentriert sich auf die Autorisierung von Anwendungen . Einige Dienste wie Facebook und Twitter haben sich jedoch dafür entschieden, OAuth für die Authentifizierung und Autorisierung zu verwenden, anstatt OpenID für die Authentifizierung und OAuth für die Autorisierung zu verwenden.

Für Ihr eigenes Projekt empfehle ich dringend, die Projektvorlage der ASP.NET MVC 2 OpenID-Website (C #) zu lesen, die in der VS-Galerie verfügbar ist. Standardmäßig werden OpenID-Authentifizierung und OAuth Service Provider unterstützt. Dies bedeutet, dass sich Ihre Benutzer mit OpenID anmelden können und Anwendungen und Dienste von Drittanbietern OAuth verwenden können, um API-Aufrufe an Ihre Website zu tätigen und auf Benutzerdaten zuzugreifen.

Wie es sich anhört, möchten Sie dieser Projektvorlage hinzufügen, sobald Sie loslegen, ist die Möglichkeit für Ihre Benutzer, sich mit Benutzername + Passwort sowie OpenID anzumelden. Wenn Sie möchten, dass Facebook und Twitter eine Option für Ihre Benutzer sind, müssen Sie dies ebenfalls implementieren, da sie den OpenID-Standard nicht verwenden. Der DotNetOpenAuth-Download enthält jedoch Beispiele für die Anmeldung bei Twitter und Facebook, sodass Sie dort einige Anleitungen haben.

Ich vermute, Sie werden an der Autorisierungsfront nicht viel zu tun haben. Es kommt mit OAuth, wie ich bereits sagte, und das wird wahrscheinlich für Sie ausreichen.

Zuerst. Sie müssen Ihre API mental von den Authentifizierungsmethoden trennen.

Ihre API besteht im Wesentlichen aus Ressourcen und Methoden zum Bearbeiten dieser Ressourcen. Sie können verschiedene Methoden zur Authentifizierung des Zugriffs auf Ihre API verwenden.

OAuth ist ein solcher Authentifizierungsmechanismus. Ein OAuth-Anbieter zu sein ist großartig, obwohl die Spezifikation etwas schwer zu verstehen ist, insbesondere die Teile, die mit Signaturen zu tun haben. Sobald Sie OAuth eingerichtet haben, können sich Clientanwendungen normalerweise leicht authentifizieren, da in den meisten Sprachen so viele "Open Source, bereits fertig, implementieren Sie einfach" -Bibliotheken verfügbar sind.

Die Vor- und Nachteile von OAuth werden seit einiger Zeit diskutiert. Um sich eine eigene Meinung zu bilden, empfehle ich Ihnen, diesen endgültigen Leitfaden zu lesen , der von Eran Hammer-Lahav , einem der Verantwortlichen für die OAuth-Spezifikation, verfasst wurde.

Die einzigen wirklichen Alternativen zu OAuth sind meines Erachtens OAuth 2.0 und nur eine einfache Basisauthentifizierung.

Davon abgesehen sprechen Sie über die Authentifizierung mit Open-ID oder Facebook-Identität usw. Dies ist eine weitere Frage, die Sie sich stellen müssen. Aber es fällt wirklich nicht in den Bereich von APIs und OAuth. Für mich ist das eher eine Frage der Benutzererstellung in Ihrem Dienst. Ich kann mich irren.