Wie unterscheidet sich OAuth 2 von OAuth 1?

604

Kann jemand in sehr einfachen Worten den Unterschied zwischen OAuth 2 und OAuth 1 erklären?

Ist OAuth 1 jetzt veraltet? Sollten wir OAuth 2 implementieren? Ich sehe nicht viele Implementierungen von OAuth 2; Die meisten verwenden immer noch OAuth 1, was mich bezweifeln lässt, dass OAuth 2 einsatzbereit ist. Ist es?

Sullivan
quelle
Bitte klären Sie; stackoverflow.com/questions/9565744/…
Lerner
Wenn Sie eine kurze Erklärung und einen detaillierten Ablauf (mit Diagrammen) von OAuth sehen möchten, können Sie oauthbible.com
Chris Ismael
Sie können Ihre Antwort hier finden OAuth 2.0 - Übersicht
John Joe

Antworten:

529

Eran Hammer-Lahav hat die meisten Unterschiede in seinem Artikel Introducing OAuth 2.0 hervorragend erklärt . Zusammenfassend sind hier die wichtigsten Unterschiede:

Mehr OAuth-Flows für eine bessere Unterstützung von nicht browserbasierten Anwendungen. Dies ist eine Hauptkritik gegen OAuth von Clientanwendungen, die nicht browserbasiert waren. In OAuth 1.0 mussten Desktop- oder Mobiltelefonanwendungen den Benutzer beispielsweise anweisen, seinen Browser für den gewünschten Dienst zu öffnen, sich beim Dienst zu authentifizieren und das Token vom Dienst zurück in die Anwendung zu kopieren. Die Hauptkritik hier ist gegen die Benutzererfahrung. Mit OAuth 2.0 gibt es jetzt neue Möglichkeiten für eine Anwendung, die Autorisierung für einen Benutzer zu erhalten.

Für OAuth 2.0 müssen Clientanwendungen nicht mehr über Kryptografie verfügen. Dies führt auf die alte Twitter-Auth-API zurück, für die keine Anwendung auf HMAC-Hash-Token und Anforderungszeichenfolgen erforderlich war. Mit OAuth 2.0 kann die Anwendung eine Anforderung nur mit dem über HTTPS ausgestellten Token stellen.

OAuth 2.0-Signaturen sind viel weniger kompliziert. Kein spezielles Parsen, Sortieren oder Codieren mehr.

OAuth 2.0-Zugriffstoken sind "kurzlebig". In der Regel können OAuth 1.0-Zugriffstoken ein Jahr oder länger gespeichert werden (Twitter lässt sie niemals ablaufen). OAuth 2.0 hat den Begriff der Aktualisierungstoken. Ich bin mir zwar nicht ganz sicher, was das ist, aber ich vermute, dass Ihre Zugriffstoken nur von kurzer Dauer sein können (dh sitzungsbasiert), während Ihre Aktualisierungstoken "Lebenszeit" sein können. Sie würden ein Aktualisierungstoken verwenden, um ein neues Zugriffstoken zu erhalten, anstatt den Benutzer Ihre Anwendung erneut autorisieren zu lassen.

Schließlich soll OAuth 2.0 eine saubere Rollentrennung zwischen dem Server, der für die Verarbeitung von OAuth-Anforderungen verantwortlich ist, und dem Server, der die Benutzerberechtigung verarbeitet, haben. Weitere Informationen hierzu finden Sie im oben genannten Artikel.

villecoder
quelle
2
Könnte jemand klären, wie sich Rückruf-URLs zwischen oauth 1 und 2 unterscheiden?
Brian Armstrong
2
OAuth 2.0 veraltet OAuth nur, wenn es als RFC zugelassen ist. Derzeit ist es ein Internet-Entwurf, aber es ist geplant, ein Internet-Standard zu werden (soweit diese Dinge geplant werden können). Dies wird jedoch Jahre dauern, da große Teile des Frameworks noch nicht spezifiziert sind. In den kommenden Jahren wird wahrscheinlich eine ganze Familie von Internet-Entwürfen veröffentlicht, die sich jeweils auf verschiedene Aspekte des OAuth 2.0-Autorisierungsrahmens beziehen. Um zu sehen, warum dies der Fall ist, besuchen Sie tools.ietf.org/html/draft-ietf-oauth-v2 und suchen Sie nach "über den Rahmen dieser Spezifikation hinaus";)
Håvard Geithus
48
Der Autor des Artikels hat letztes Jahr ein Follow-up mit dem Titel "OAuth 2.0 und der Weg zur Hölle" geschrieben, das hier gelesen werden kann: web.archive.org/web/20120731155632/http://hueniverse.com/2012/… Ein wesentlicher Unterschied zwischen beiden ist die Sicherheit - wie durch den Mangel an Kryptographie in 2.0 angedeutet.
kdazzle
4
Die Sicherheit von OAuth 1.0 basiert auf der Annahme, dass ein in eine Clientanwendung eingebetteter geheimer Schlüssel vertraulich behandelt werden kann, die Annahme ist jedoch naiv. In OAuth 2.0 wird eine solche naive Client-Anwendung als vertraulicher Client bezeichnet . Es gibt keinen praktischen Unterschied in der Sicherheitsstufe zwischen OAuth 1.0-Clients und vertraulichen OAuth 2.0-Clients. "OAuth 2.0 und der Weg zur Hölle" verfehlt diesen Punkt.
Takahiko Kawasaki
6
@kdazzle, dieser Link ist jetzt hierher verschoben
e_i_pi
193

Ich sehe hier oben großartige Antworten, aber was ich vermisse, sind einige Diagramme, und da ich mit Spring Framework arbeiten musste, bin ich auf deren Erklärung gestoßen .

Ich finde die folgenden Diagramme sehr nützlich. Sie veranschaulichen den Unterschied in der Kommunikation zwischen Parteien mit OAuth2 und OAuth1.


OAuth 2

Geben Sie hier die Bildbeschreibung ein


OAuth 1

Geben Sie hier die Bildbeschreibung ein

nyxz
quelle
3
Wo wird "client_secret" in diesem Ablauf verwendet?
ashwintastic
3
Wenn Sie das Geheimnis meinen, das der Benutzer eingibt, wenn er an den Anbieter weitergeleitet wird (z. B. Facebook, Twitter, Google usw.), ist dies Schritt 2 für OAuth 2und Schritt 4 für OAuth 1.
Nyxz
Warum haben beide Diagramme einen Dienstanbieterschritt mit dem Namen "Benutzer gewährt Autorisierung"? Dies scheint rückwärts oder falsch. Ist nicht der "Benutzer" derjenige, der eine Autorisierung sucht?
Forbin
@Forbin Da dieser Schritt auf der Seite des Dienstanbieters erfolgt. Sie befinden sich auf ihrer Seite, auf der Sie die Zuschüsse sehen, die der Dienst von Ihnen benötigt, und Sie müssen zustimmen, diese Informationen mit dem Dienst zu teilen, bei dem Sie sich authentifizieren möchten. StackOverflow hat tatsächlich die Möglichkeit, sich mit einem Google-Konto anzumelden. Es funktioniert genauso. SO wird Google bitten, Ihre E-Mail-Adresse anzuzeigen, und Sie müssen dem zustimmen.
Nyxz
91

Die vorherigen Erklärungen sind alle zu detailliert und kompliziert IMO. Einfach ausgedrückt delegiert OAuth 2 die Sicherheit an das HTTPS-Protokoll. OAuth 1 benötigte dies nicht und verfügte folglich über alternative Methoden, um mit verschiedenen Angriffen umzugehen. Diese Methoden erforderten von der Anwendung die Verwendung bestimmter Sicherheitsprotokolle, die kompliziert sind und schwierig zu implementieren sein können. Daher ist es einfacher, sich aus Sicherheitsgründen nur auf HTTPS zu verlassen, damit sich Anwendungsentwickler keine Sorgen machen müssen.

Die Antwort auf Ihre anderen Fragen hängt davon ab. Einige Dienste möchten nicht die Verwendung von HTTPS erfordern, wurden vor OAuth 2 entwickelt oder haben andere Anforderungen, die sie möglicherweise daran hindern, OAuth 2 zu verwenden. Darüber hinaus wurde viel über das OAuth 2-Protokoll selbst diskutiert. Wie Sie sehen können, haben Facebook, Google und einige andere jeweils leicht unterschiedliche Versionen der implementierten Protokolle. Einige Leute bleiben also bei OAuth 1, weil es auf den verschiedenen Plattformen einheitlicher ist. Vor kurzem wurde das OAuth 2-Protokoll fertiggestellt, aber wir müssen noch sehen, wie es angenommen wird.

chacham15
quelle
11
OAuth2 funktioniert also grundsätzlich mit HTTPS und ist daher einfacher als OAuth1, was etwas komplexer sein muss, da es ohne HTTPS funktionieren kann?
Micro
@MicroR Dies ist eine praktische Definition, die Sie dort erhalten haben! ;)
EralpB
36

Beachten Sie, dass es schwerwiegende Sicherheitsargumente gegen die Verwendung von Oauth 2 gibt:

ein trostloser Artikel

und eine technischere

Beachten Sie, dass diese vom Hauptautor von Oauth 2 stammen.

Wichtige Punkte:

  • Oauth 2 bietet keine Sicherheit zusätzlich zu SSL, während Oauth 1 transportunabhängig ist.

  • In gewisser Weise ist SSL nicht sicher, da der Server die Verbindung nicht überprüft und die allgemeinen Clientbibliotheken das Ignorieren von Fehlern erleichtern.

    Das Problem mit SSL / TLS besteht darin, dass die Verbindung weiterhin funktioniert, wenn Sie das Zertifikat auf der Clientseite nicht überprüfen können. Jedes Mal, wenn das Ignorieren eines Fehlers zum Erfolg führt, werden Entwickler genau das tun. Der Server hat keine Möglichkeit, die Zertifikatsüberprüfung zu erzwingen, und selbst wenn dies möglich wäre, wird ein Angreifer dies sicherlich nicht tun.

  • Sie können Ihre gesamte Sicherheit verlieren, was in OAuth 1.0 viel schwieriger ist:

    Das zweite häufige potenzielle Problem sind Tippfehler. Würden Sie es als richtiges Design betrachten, wenn ein Zeichen (das 's' in 'https') weggelassen wird, wodurch die gesamte Sicherheit des Tokens ungültig wird? Oder senden Sie die Anfrage (über eine gültige und verifizierte SSL / TLS-Verbindung) an das falsche Ziel (z. B. " http://gacebook.com "?). Denken Sie daran, dass die Verwendung von OAuth-Träger-Token über die Befehlszeile eindeutig ein Befürworter von Befürwortern von Anwendungsfall-Träger-Token war.

Djechlin
quelle
4
Das "Tippfehler" -Argument ist nicht sehr gültig - es ist übliche Praxis, von http zu https umzuleiten
Oleg Mikheev
2
@OlegMikheev Ja, aber es ist nur eine http (no-s) -Anforderung erforderlich, damit ein MITM Ihre Header abhören kann und Ihr Token jetzt von jemand anderem verwendet wird!
Patrick James McDougle
3
Wenn Sie mit Headern Cookies meinen, sollten diese sicher sein . Abgesehen davon sehe ich nicht, wie Benutzertippfehler (in der Browser-URL) Token
anzeigen
2
Als zusätzlichen Punkt gegen das Argument "Tippfehler" kann ein Dienstanbieter alle OAuth 2.0-Anforderungen, die nicht über https erfolgen, ablehnen und das Zugriffstoken in dieser Anforderung widerrufen.
Skeller88
32

Die Sicherheit des OAuth 1.0-Protokolls ( RFC 5849 ) basiert auf der Annahme, dass ein in eine Clientanwendung eingebetteter geheimer Schlüssel vertraulich behandelt werden kann. Die Annahme ist jedoch naiv.

In OAuth 2.0 ( RFC 6749 ) wird eine solche naive Clientanwendung als vertraulicher Client bezeichnet. Andererseits wird eine Clientanwendung in einer Umgebung, in der es schwierig ist, einen geheimen Schlüssel vertraulich zu behandeln, als öffentlicher Client bezeichnet. Siehe 2.1. Client-Typen für Details.

In diesem Sinne ist OAuth 1.0 eine Spezifikation nur für vertrauliche Clients.

" OAuth 2.0 und der Weg zur Hölle " besagt, dass OAuth 2.0 weniger sicher ist, es jedoch keinen praktischen Unterschied in der Sicherheitsstufe zwischen OAuth 1.0-Clients und vertraulichen OAuth 2.0-Clients gibt. OAuth 1.0 erfordert die Berechnung der Signatur, erhöht jedoch nicht die Sicherheit, wenn bereits sichergestellt ist, dass ein geheimer Schlüssel auf der Clientseite vertraulich behandelt werden kann. Das Berechnen der Signatur ist nur eine umständliche Berechnung ohne praktische Sicherheitsverbesserung. Ich meine, im Vergleich zu der Einfachheit , dass ein OAuth 2.0 - Client eine Verbindung zu einem Server über TLS und einfach präsentiert client_idund client_secretkann nicht gesagt werden , dass die umständliche Berechnung besser ist in Bezug auf die Sicherheit.

Darüber hinaus erwähnt RFC 5849 (OAuth 1.0) nichts über offene Redirektoren, während RFC 6749 (OAuth 2.0) dies tut. Das heißt, der oauth_callbackParameter von OAuth 1.0 kann zu einer Sicherheitslücke werden.

Daher denke ich nicht, dass OAuth 1.0 sicherer ist als OAuth 2.0.


[14. April 2016] Ergänzung zur Klarstellung meines Punktes

Die OAuth 1.0-Sicherheit basiert auf der Signaturberechnung. Eine Signatur wird unter Verwendung eines geheimen Schlüssels berechnet, wobei ein geheimer Schlüssel ein gemeinsam genutzter Schlüssel für HMAC-SHA1 ( RFC 5849, 3.4.2 ) oder ein privater Schlüssel für RSA-SHA1 ( RFC 5849, 3.4.3 ) ist. Jeder, der den geheimen Schlüssel kennt, kann die Signatur berechnen. Wenn also der geheime Schlüssel kompromittiert wird, ist die Komplexität der Signaturberechnung bedeutungslos, wie komplex sie auch sein mag.

Dies bedeutet, dass die Sicherheit von OAuth 1.0 nicht von der Komplexität und Logik der Signaturberechnung abhängt, sondern lediglich von der Vertraulichkeit eines geheimen Schlüssels. Mit anderen Worten, was für die OAuth 1.0-Sicherheit benötigt wird, ist nur die Bedingung, dass ein geheimer Schlüssel vertraulich behandelt werden kann. Dies mag extrem klingen, aber die Signaturberechnung fügt keine Sicherheitsverbesserung hinzu, wenn die Bedingung bereits erfüllt ist.

Ebenso verlassen sich vertrauliche OAuth 2.0- Clients auf dieselbe Bedingung. Wenn die Bedingung bereits erfüllt ist, gibt es ein Problem beim Erstellen einer sicheren Verbindung mit TLS und beim Senden client_idund Senden client_secretan einen Autorisierungsserver über die gesicherte Verbindung? Gibt es einen großen Unterschied in der Sicherheitsstufe zwischen vertraulichen OAuth 1.0- und OAuth 2.0-Clients, wenn beide auf derselben Bedingung beruhen?

Ich kann keinen guten Grund für OAuth 1.0 finden, OAuth 2.0 zu beschuldigen. Tatsache ist einfach, dass (1) OAuth 1.0 nur eine Spezifikation nur für vertrauliche Clients ist und (2) OAuth 2.0 das Protokoll auch für vertrauliche Clients und unterstützte öffentliche Clients vereinfacht hat . Unabhängig davon, ob dies bekannt ist oder nicht, werden Smartphone-Anwendungen als öffentliche Clients ( RFC 6749, 9 ) klassifiziert , die von OAuth 2.0 profitieren.

Takahiko Kawasaki
quelle
7
Das Senden von Geheimnissen anstelle von Signaturen, sei es über HTTP, HTTPS usw., birgt aufgrund von MITM auf Protokollebene immer ein implizites Sicherheitsrisiko. Jetzt gibt es zwei Möglichkeiten, um Geheimnisse zu finden, anstatt nur eine: das Gerät rooten oder Root-Zertifikate fälschen (ist schon einmal passiert, also nicht weit hergeholt). Wenn Ihr Sicherheitsmodell "eh, lassen Sie den Transport damit umgehen" lautet, ist es wahr, dass es nicht WENIGER sicher ist als das Protokoll. Aber monolithische Sicherheitsmodelle == ein Einstiegspunkt für viele Dienste. Es ist "gut genug" für pragmatische Ingenieure, aber es wird niemals "so sicher" sein wie ein alternatives dezentrales Modell.
Mark G.
23

OAuth 2.0-Signaturen sind für die tatsächlichen API-Aufrufe nicht erforderlich, sobald das Token generiert wurde. Es gibt nur ein Sicherheitstoken.

Für OAuth 1.0 muss der Client zwei Sicherheitstoken für jeden API-Aufruf senden und beide zum Generieren der Signatur verwenden. Die Endpunkte der geschützten Ressourcen müssen Zugriff auf die Clientanmeldeinformationen haben, um die Anforderung zu validieren.

Hier wird der Unterschied zwischen OAuth 1.0 und 2.0 beschrieben und wie beide funktionieren.

Fionaa Miller
quelle
22

OAuth 2 ist anscheinend Zeitverschwendung (aus dem Mund von jemandem, der stark daran beteiligt war):

https://hueniverse.com/oauth-2-0-and-the-road-to-hell-8eec45921529

Er sagt (der Kürze halber bearbeitet und zur Hervorhebung fett gedruckt):

... Ich kann nicht mehr mit dem OAuth 2.0-Standard verknüpft werden. Ich gab meine Rolle als Hauptautor und Herausgeber auf, zog meinen Namen aus der Spezifikation zurück und verließ die Arbeitsgruppe. Es war nicht einfach, meinen Namen aus einem Dokument zu entfernen, an dem ich drei Jahre lang sorgfältig gearbeitet habe, und über zwei Dutzend Entwürfe waren nicht einfach. Die Entscheidung, mich von einer Anstrengung zu lösen, die ich seit über fünf Jahren führe, war qualvoll.

... Am Ende bin ich zu dem Schluss gekommen, dass OAuth 2.0 ein schlechtes Protokoll ist. WS- * schlecht. Es ist schon schlimm genug, dass ich nicht mehr damit in Verbindung gebracht werden möchte. ... Im Vergleich zu OAuth 1.0 ist die 2.0-Spezifikation komplexer, weniger interoperabel, weniger nützlich, unvollständiger und vor allem weniger sicher.

Um klar zu sein, wird OAuth 2.0 von einem Entwickler mit tiefem Verständnis der Websicherheit wahrscheinlich zu einer sicheren Implementierung führen. In den Händen der meisten Entwickler wird 2.0 - wie die Erfahrung der letzten zwei Jahre gezeigt hat - wahrscheinlich zu unsicheren Implementierungen führen.

Tony Knibb
quelle
7
Beachten Sie, dass von Antworten nur mit Links abgeraten wird und Referenzen im Laufe der Zeit veralten. Bitte fügen Sie hier eine eigenständige Zusammenfassung hinzu, wobei Sie den Link als Referenz behalten.
Kleopatra
6
Die Sicherheit von OAuth 1.0 basiert auf der Annahme, dass ein in eine Clientanwendung eingebetteter geheimer Schlüssel vertraulich behandelt werden kann. Bei Smartphone-Anwendungen ist diese Annahme jedoch naiv. In OAuth 2.0 wird eine solche naive Client-Anwendung als vertraulicher Client bezeichnet . Es gibt keinen praktischen Unterschied in der Sicherheitsstufe zwischen OAuth 1.0-Clients und vertraulichen OAuth 2.0-Clients. "OAuth 2.0 und der Weg zur Hölle" verfehlt diesen Punkt.
Takahiko Kawasaki
15

Wenn Sie eine ausführliche Erklärung benötigen, müssen Sie beide Spezifikationen lesen:

https://oauth.net/core/1.0a/

https://oauth.net/2/

Wenn Sie eine klare Erklärung der Flussunterschiede benötigen, kann dies hilfreich sein:

OAuth 1.0 Flow

  1. Die Clientanwendung wird beim Anbieter registriert, z. B. bei Twitter.
  2. Twitter bietet dem Kunden ein für diese Anwendung einzigartiges „Verbrauchergeheimnis“.
  3. Die Client-App signiert alle OAuth-Anfragen bei Twitter mit ihrem einzigartigen „Verbrauchergeheimnis“.
  4. Wenn eine der OAuth-Anforderungen fehlerhaft ist, Daten fehlen oder nicht ordnungsgemäß signiert sind, wird die Anforderung abgelehnt.

OAuth 2.0 Flow

  1. Die Clientanwendung wird beim Anbieter registriert, z. B. bei Twitter.
  2. Twitter bietet dem Kunden ein für diese Anwendung einzigartiges „Kundengeheimnis“.
  3. Die Client-Anwendung enthält "Client Secret" mit jeder Anforderung, die üblicherweise als http-Header bezeichnet wird.
  4. Wenn eine der OAuth-Anforderungen fehlerhaft ist, Daten fehlen oder das falsche Geheimnis enthalten, wird die Anforderung abgelehnt.

Quelle: https://codiscope.com/oauth-2-0-vs-oauth-1-0/

JRichardsz
quelle
2
Könnten Sie die Zeichen Fettdruck sehen? Möglicherweise könnte funktional das gleiche Konzept haben, aber technisch gesehen ist es sehr unterschiedlich, die gesamte Anfrage zu signieren, wenn Sie einen einfachen Header (oauth2) verwenden . Achten Sie darauf und verbessern Sie Ihr Leseverständnis, bevor Sie Antworten als nicht nützlich markieren
JRichardsz
1
Bitte lesen Sie Ihre eigene Antwort und versuchen Sie, einen Sinn daraus zu machen. "Signiert alle Anfragen mit geheimen" und "geheime Anfragen mit allen Anfragen senden". Niemand, der bei klarem Verstand ist, wird den Unterschied hier verstehen, wenn er sie nicht bereits benutzt hat. Ich kenne den Unterschied, aber das OP nicht. Diese Antwort wird OP nur weiter verwirren, daher die Abstimmungen. Solche vagen Antworten verdienen eine Ablehnung. Bitte lesen Sie hier andere Antworten, die weitaus spezifischer und informativer sind.
Saran3h
12 Entwickler haben es verstanden. oauth1 & oauth2 haben viele Unterschiede. Frühere Antworten decken sie ab. Wie gesagt , Sie können dieses oauth.net/core/1.0a oder dieses oauth.net/2 lesen , um Ihre eigene Antwort zu geben. Mein Ziel ist es, einen der bekanntesten technischen Unterschiede aufzuzeigen, wenn ein Entwickler einen Rest-Client entwickeln muss.
JRichardsz
7

OAuth 2.0 verspricht, die Dinge auf folgende Weise zu vereinfachen:

  1. SSL ist für die gesamte Kommunikation erforderlich, die zum Generieren des Tokens erforderlich ist. Dies ist eine enorme Verringerung der Komplexität, da diese komplexen Signaturen nicht mehr benötigt werden.
  2. Für die eigentlichen API-Aufrufe nach der Generierung des Tokens sind keine Signaturen erforderlich. Auch hier wird SSL dringend empfohlen.
  3. Nach der Generierung des Tokens erforderte OAuth 1.0, dass der Client bei jedem API-Aufruf zwei Sicherheitstoken sendet und beide zum Generieren der Signatur verwendet. OAuth 2.0 verfügt nur über ein Sicherheitstoken, und es ist keine Signatur erforderlich.
  4. Es ist klar festgelegt, welche Teile des Protokolls vom "Ressourcenbesitzer" implementiert werden, welcher der eigentliche Server ist, der die API implementiert, und welche Teile von einem separaten "Autorisierungsserver" implementiert werden können. Dadurch können Produkte wie Apigee vorhandene APIs mit OAuth 2.0 unterstützen.

Quelle: http://blog.apigee.com/detail/oauth_differences

Abhijit Gaikwad
quelle
1

Aus Sicherheitsgründen würde ich mich für OAuth 1 entscheiden. Siehe OAuth 2.0 und den Weg zur Hölle

Zitat aus diesem Link: "Wenn Sie 1.0 derzeit erfolgreich verwenden, ignorieren Sie 2.0. Es bietet keinen wirklichen Wert über 1.0 (ich vermute, Ihre Client-Entwickler haben bereits 1.0-Signaturen herausgefunden).

Wenn Sie neu in diesem Bereich sind und sich als Sicherheitsexperte betrachten, verwenden Sie 2.0 nach sorgfältiger Prüfung der Funktionen. Wenn Sie kein Experte sind, verwenden Sie entweder 1.0 oder kopieren Sie die 2.0-Implementierung eines Anbieters, dem Sie vertrauen, um sie richtig zu machen (die API-Dokumente von Facebook sind ein guter Ausgangspunkt). 2.0 ist besser für große Unternehmen, aber wenn Sie einen größeren Vorgang ausführen, haben Sie wahrscheinlich einige Sicherheitsexperten vor Ort, die alles für Sie herausfinden. "

harmv
quelle