Was ist OAuth2?

17.02.2017

OAuth2 ist ein Sicherheitsprotokoll, um eine Webapplikation sicher zu machen und Benutzer zu authentifizieren und authorisieren. OAuth2 wird etwa bei Facebook oder Github verwendet.

Warum OAuth2?

Eine typische Webapplikation wird vom Benutzer am Client verwendet, welcher sich beim Server anmelden muss, zum Beispiel über REST Services. Normalerweise verwendet der Benutzer dafür seinen Benutzernamen und ein Passwort. Diese könnte man nun mit jeder REST Anfrage mitsenden. Dies hat aber einen Nachteil: Benutzername und Passwort müssten bei jeder Anfrage vom Server überprüft werden.

Häufig sind Services mit BasicAuth geschützt. Dort wird bei jeder Anfrage der Benutzername und das Passwort im Header mitgeschickt, codiert mit Base64.

Der Vorteil von OAuth2 ist, dass das Passwort nur einmal beim Login verschickt werden muss. Zurück kommen dann zwei Tokens, das Access Token und das Refresh Token. Das Access Token hat dabei eine beschränkte Gültigkeit. Falls dieses abgelaufen ist, kann der Client ein neues mit Hilfe des Refresh Token bestellen.

Die Tokens werden üblicherweise persistiert, weil in einer modernen Infrastruktur verschiedene Instanzen von Applikationsserver die Benutzerrequests bearbeiten können und dafür Zugriff auf die Tokens benötigen.

Wie funktioniert die Anmeldung?

OAuth2 verwendet also Zugriffstokens / Access Tokens für Anfragen und verzichtet vollständig auf digitale Signaturen, was den Umgang viel einfacher macht. Zum Glück setzt OAuth2 auch vollständig auf HTTPS.

Folgende Schritte werden in OAuth2 gemacht:

1. Der Benutzer wird nach seinem Benutzernamen und Passwort gefragt. Diese werden dem Server, etwa eine Buchhaltungswebpage, übergeben. Der Benutzer erhält dann einen sogenannten Access Grant, also die Erlaubnis, weiterzumachen.
2. Die Anfrage wird zum Authorisierungsserver weitergeleitet, der die Daten prüft.
3. Sind die Daten gültig, erstellt der Server ein Access Token und ein Refresh Token
4. Mit dem Access Token kann der Benutzer nun auf die Dienste des Anbieters zugreifen

Im OAuth2 Jargon redet man dabei vom Serviceanbieter von einem Ressource Owner, das sich das Protokoll als ressourcenbasiert sieht.

Was für eine Antwort erhält man von der Authentifizierung?

Wenn die Anmeldung beim Authorisierungsserver geklappt hat, erhält man eine Antwort im JSON Format mit den relevanten Informationen:

{
"access_token": "asdfwerpoiupou",
"token_type": "Bearer",
"expires_in": 3600,
"refresh_token": "opiulfgasdfwer"
}

Darin steht auch gleich, wie lange das Token gültig ist.

Was ist der Token Type Bearer?

Das Token, dass man erhält, ist ein sogenanntes Bearer Token. Mit diesem kann man auf die gewünschten Ressourcen zugreifen. Damit das Token geschützt bleibt, sollte es über eine mit TLS gesichterte Verbindung gehen – weshalb TLS auch Voraussetzung ist für die Verwendung des Tokens.

Das Access Token muss dann in der nächsten Anfrage im Authorization Header mitgeschickt werden.

In Java kann man den Authorization Header folgendermassen befüllen:

HttpPost request = new HttpPost("http://example.com/auth");
request.addHeader("Authorization", "Basic asdfwerpoiupou ");

JWT bei Architektur mit vielen Applikationsinstanzen

Wie gesagt muss das Token auf die eine oder andere Art persistiert werden. Dies kann zum Beispiel über eine In Memory Datenbank geschehen. Diese Datenbank hätte dann den Zugriff auf alle Applikationsinstanzen geben müssen, welche die Token benötigen. Hat man etwa einen REST Service, der OAuth2 verwendet, zwanzig Mal instanziert, müssen diese Instanzen das Token lesen können.

Eine weitere Option wäre der Einsatz von JSON Web Tokens = JWT. Die Authentifizierung erfolgt dabei mit einem Schlüssel, der sich aus verschiedenen Metainformationen des Benutzers zusammensetzt. So kann jede Instanz des Services prüfen, ob das aktuelle Token gültig ist.

Um zu prüfen, ob ein Token für den Benutzer existiert, wird ein JWT Repository angefragt. Es entschlüsselt das Token und gibt die benötigten Informationen zurück.

Besuchen Sie doch einmal https://jwt.io/ um ein Beispiel eines Tokens zu sehen. Im Header wird der Verschlüsselungsalgorithmus genannt. Im Payload sieht man schön die Daten wie etwa der Name des Benutzers.

Was ist der Unterschied zwischen Sockets und REST Services?

16.02.2017

Sockets werden für die Netzwerkprogrammierung verwendet, genauso wie REST oder SOAP Services. Man will also, dass zwei Rechner miteinander sprechen können.

Wann sollte man aber Sockets nehmen und wann REST Services?

Das Protokoll macht den Unterschied

Im Informatikstudium durften wir in einem Fach einen eigenen Chat in Java programmieren. Dazu haben wir Sockets verwendet. Man hat also auf zwei Rechnern je einen Chat Client gestartet, die miteinander reden sollten. Nun war aber noch die Frage, wie die Daten ausgetauscht werden müssen? Eine Nachricht erhält ja mindestens ein Datum, den Chatnamen und die Nachricht.

Für die Definition dieser Nachricht mussten wir ein Protokoll erstellen. Ein Protokoll, welches sagt: „An erster Stelle kommt das Datum, dann der Chatname“ und so weiter. Dieses Protokoll oder Nachrichtenformat konnten wir dann beliebig zwischen uns Studenten austauschen. Sobald mein Kollege mein Protokoll hatte, konnte er seine Implementierung des Chats mit diesem Protokoll versehen und fortan wusste er, wie ich Nachrichten an ihn senden würde.

REST und HTTP und SOAP

Genauso muss wohl auch die Entwicklung der bekannten Protokolle gestartet haben. Irgendwann denkt man nämlich „ja gut, mein Kollege und ich können nun Nachrichten austauschen, aber was ist, wenn ich etwa einen Dienst von Google aufrufen will? Dann muss ich denen klar machen, wie mein Protokoll aussieht?“

Genau dafür wurden Protokolle standardisiert und sind heute im Einsatz. Das HTTP Protokoll für den Austausch über das Internet. REST Services für den Zugriff auf Ressourcen und SOAP Webservices für explizite Dienstleistungen.

Wie sieht das in der TCP/IP Architektur aus?

Die TCP/IP Architektur ist ein Ausschnitt vom ISO/OSI-Modell und hat vier Schichten:

1. Die Schnittstellensicht ist quasi ganz unten und steht für die physische Verbindung vom Rechner zum Netz.

2. Die nächste Schicht ist die Internetschicht, die zum Aufbau und Betreiben einer Kommunikation zwischen Rechnen in einem Netzwerk dient. Dort ist auch das Internet Protokoll (IP) zuhause.

3. Die dritte Schicht ist die Transportschicht, welche den Programmen auf einem Rechner Transportdienste zur Verfügung stellt. Hier kommt entweder TCP oder UDP zum Einsatz. Auf dieser Ebene finden auch Sockets statt.

4. Die oberste Schicht ist die Anwendungsschicht. Hier geht es um die konkreten Anwendungen auf einem Rechner. Diese Schicht enthält unter anderem die Protokolle HTTP oder FTP. REST verwendet für die Übertragung das HTTP oder HTTPS Protokoll auf dieser Schicht. Bei SOAP können zum Senden von Nachrichten beliebige Transportprotokolle verwendet werden, etwa FTP, SMTP, HTTP oder auch JMS. Meistens wird aber auch hier das HTTP oder HTTPS Protokoll verwendet.

Und was ist mit Websockets?

Websocket ist ebenfalls ein Protokoll für die Übertragung über das Netz – Im Gegensatz zu Sockets liegt dieses aber auf der Anwendungsschicht, nicht auf der Transportschicht. Das Thema Websockets wäre aber wohl genug Stoff für einen eigenen Blogeintrag.

Was ist ein verteiltes System?

13.02.2017

Grosse Applikationen in einem Unternehmen laufen heutzutage nicht mehr auf einem einzigen Rechner, sondern auf mehreren Servern. Ist eigentlich auch logisch, denn wenn der Hauptcomputer ausfallen würde und man etwa die Buchhaltungsapplikation nicht mehr verwenden könnte, wäre das nicht gerade optimal.

Läuft eine Applikation auf mehreren Servern spricht man von einem verteilten System. Bei ganz grossen Firmen ist das System nicht nur verteilt auf mehrere Server, sondern die Server selber sind auch von der Lokation her an verschiedenen Orten. Die Daten werden dann üblicherweise dupliziert und redundant gehalten. So kann ein Serverzentrum die volle Funktionalität übernehmen, wenn das zweite ausfallen würde – Am Besten so, dass der Kunde nichts davon merkt.

Was sind die Vorteile von verteilten Systemen?

Nun, wie erwähnt will man die Ausfallsicherheit eines Systems erhöhen. Stellen Sie sich vor, das Ebanking ihrer Bank würde für eine Woche ausfallen – Das wäre eine Katastrophe!

Desweiteren hat man bei einem verteilten System die Möglichkeit, bei der Überlastung eines Servers die Last auf weitere Server zu verteilen, siehe Was ist ein Load Balancer?

Aus diesen Gründen ist es daher sowieso keine Frage, ob grosse Firmen ein verteiltes System verwenden oder nicht. Systeme von Grossfirmen sind mittlerweile riesig und über etliche Jahre gewachsen. Systeme haben auch die Natur, dass sie sich ständig ändern. Daher muss die Architektur so skalierbar sein wie möglich.

Was ist eine typische Architektur eines verteilten Systems?

Eine Architektur, die man am sehr oft antrifft, ist die sogenannte Three Tier Architektur. Mit Tier ist dabei einfach eine Stufe einer Applikation gemeint.

Beim Tier 1 geht es um den Kunden, der an seinem Computer sitzt und die Anwendung er Firma benutzt. Er wird üblicherweise Client genannt. Diese Stufe findet also beim Kunden auf seinem Computer statt – Heutzutage normalerweise im Browser, da man praktisch nur noch Webapps baut statt echte Desktopprogramme.

Der Tier 2 geschieht dann bereits auf den Servern einer Firma. Dort läuft die Stufe der Anwendungsserver oder Applikationsserver. Die Benutzereingaben werden dort gesammelt und je nachdem, was gemacht werden muss, werden verschiedene Module aufgerufen. Dort ist auch der Kern oder der Wert einer Firma versteckt: In den Algorithmen und der Geschäftslogik.

Im Tier 3 geht es dann noch darum, die Daten zu persistieren und auf Datenbanken abzuspeichern.

Haben alle Firmen dieselbe Architektur?

Ha, schön wäre es! Wie es in der Natur des Menschen liegt, hat jede Firma ihre eigene Architektur und sogar innerhalb einer Firma existieren zig Architekturen, die verwendet werden. Alte Systeme werden am Leben gelassen, weil man zum Beispiel den alten Code nicht mehr versteht und lieber nichts ändert. Neue Systeme richten sich nicht an alten Systemen. Mitarbeiter werden ausgetauscht, die jeweils unterschiedliche Technologien bevorzugen oder kennen – Da passiert viel in einer wirklich grossen Firma.

Denken Sie auch daran, dass die Three Tier Architektur wirklich nur ein ganz grundlegender, traditioneller Gedanke ist. Innerhalb einer Stufe können verschiedene Unterstufen und Technolgien zum Einsatz kommen.

Ein Client kann zum Beispiel eine mit Java und JavaScript gebaute Buchhaltungssoftware verwenden, die per REST Services mit dem Applikationsserver kommuniziert. Im Applikationsserver gibt es nun eine Applikation, welche die Benutzerdaten in einer Oracle Datenbank abspeichert und mit Java darauf zugreift. Die Buchhaltungsdaten selber werden aber an einen Cobolservice weitergereicht, der diese Daten wiederum in einer DB2 Datenbank abspeichert.

Sie sehen, in der Realität können sehr viele Stufen durchlaufen werden, wenn man in einer Webapplikation einen simplen Knopfdruck macht.