Einführung in OAuth 2.0

Florian Horn // 11.12.2015

Agenda

• Definition, Ziele und Benefits von OAuth
• Abgrenzung OAuth
• Allgemeiner Ablauf

Was ist OAuth 2.0?

• Protokoll zur Authorisierungs-Delegation
• Definiert Rollen und Abläufe für diverse Anforderungen
• Definiert nicht die Implementierung
• Basiert auf HTTP, andere Protokolle werde offiziell nicht supported
• Definiert im RFC 6749, seit Oktober 2012 abgenommen
• Ersetzt OAuth 1.0 (RFC 5849) (nicht kompatibel)

Ziele und Benefits

• Framework zur Vergabe von begrenzten Zugriffen auf Ressourcen
• Zugriffe für sich selbst oder im Namen anderer
• Unterschiedlich komplexe Freigabeprozesse für Zugriffsrechte
• Erweiterbarkeit der Freigabeprozesse
• Separierung der Verantwortlichkeiten auf Basis der Rollen
• Fokus der Zugriffsfreigabe liegt auf Anwendungen Dritter

Ziele und Benefits

OAuth 2.0 regelt:

Wer darf was für wen wie lange machen?

• Klassisch: Ressourcen-Service übernimmt Authentifizierung und Authorisierung
• OAuth 2.0: Trennung von Verantwortlichkeit für Authorisierung und Ressource
• Zielt auf die Absicherung von APIs

Abgrenzung OAuth 2.0

OAuth 2.0 regelt nicht:

• Die konkrete Implementierung
• Die verwendeten Crypto-Mechanismen (Token-Generierung)
  • Bearer-Token: RFC 6750
  • MAC-Token: seit 2011 im Draft
• Zwingt nicht auf HTTPS (ursprünglich im Draft vorgesehen)

Abgrenzung OAuth 2.0

Wo kann OAuth 2.0 verwendet werden?

• Klassischen Programmiersprachen wie Java und PHP
• Noch viele weitere: Python, Ruby, .NET, NodeJS, Erlang, ...
• Ebenso nutzbar in Javascript (reine Client-seitige Ausführung)
• Solange Kommunikation über HTTP(S)

OAuth 2.0 Rollen

Resource Owner (auch End User)

Initialisiert die Resourcen-Abfrage

Resource Server

Liefert Resource nach Verifizierung aus

Client

Applikation, die die Resourcen-Abfrage ausführt

Authorization Server

Service zur Vergabe und Überprüfung von Authorisierungs-Tokens (und mehr)

Grant Types

Grant ist ein Zugriffs-Berechtigungsnachweis, meist Benutzername und Passwort.

Grant Types definieren den Authorisierungs-Workflow.

• User Credentials
• Client Credentials
• Authorization Code
• Implicit
• Erweiterbar durch eigene Grant Types

Grant Types

Grant ist ein Zugriffs-Berechtigungsnachweis, meist Benutzername und Passwort.

Grant Types definieren den Authorisierungs-Workflow.

Hinweis: Es ist der Implementierung überlassen, wie der Token beim Resource Server überprüft wird. In der Regel passiert das durch Gegenprüfung beim Authorization Server.

Access Token

• Zeichenkette
• Generiert vom Authorization Server
• Wird verwendet vom Client und geprüft vom Resource Server
• Gültigkeit zeitlich begrenzt (Expire), sehr kurzlebig (~ 1h)
• Umfang des Zugriffs begrenzt (Scope)
• Gültigkeit kann jederzeit widersprochen werden

Refresh Token

• Sind optional
• Zeichenkette
• Generiert vom Authorization Server
• Wird verwendet vom Client und (ausschließlich!) geprüft vom Authorization Server
• Gültigkeit optional zeitlich begrenzt (Expire), langlebig (Wochen bis unendlich)
• Umfang des Zugriffs begrenzt (Scope)
• Gültigkeit kann jederzeit widersprochen werden
• Client erhält neuen Access Token mit gleichem Scope ohne das Mitsenden des ursprünglichen Grants

Benefits von OAuth 2.0

• Trennung der Services für die Authentifizierung und Authorisierung vom Resource-Service
• Authorisierungs-Prozess frei wählbar nach Anforderungen
• Authorisierungs-Prozess austauschbar, am Ende gibt es immer einen Token
• Resource-Service muss nur noch den einheitlichen Token-Ablauf verstehen
• Beim Auth-Code-Verfahren erfährt der Client nie den EndUser-Grant!

Bekannte OAuth Services

• Google
• Facebook Graph
• Dropbox
• GitHub
• Meetup
• ...

Aus, Schluss, Ende!

Bei Anregungen, Feedback oder Fragen einfach melden!