In OAuth 4 Dummies habe ich erläutert wie das Authorisierungsprotokoll OAuth funktioniert und wozu man es einsetzen kann. Es ging darum jemanden den Schlüssel zu meiner Wohnung sicher zu übergeben. Wie sich herausstellte, ist OAuth zwar in der Lage den Schlüssel sicher weiter zu geben, also die Authorisierung zu verwalten, leider kann man damit aber nicht sicherstellen, wem man den Schlüssel übergibt (Authentifizierung).

Das ist natürlich ein großes Problem, ich möchte ja nicht, dass Irgend Jemand in meine Wohnung kommt um die Katze zu füttern (und wer weiß was sonst noch darin tut). Die Konsequenz führte zur Entwicklung von eigenen Erweiterungen, wie z.B. der von Facebook bekannten Graph API (https://en.wikipedia.org/wiki/Facebook_Platform).

Die Graph API ist nun aber speziell von FB für FB entwickelt. Daher sind viele Anwendungsfälle nicht abgedeckt. OAuth wurde bereits 2008 an IETF übergeben und ist seit dem quasi ein Standard. Innerhalb kurzer Zeit wurde es von vielen bekannten Plattformen, wie z.B. Twitter oder Google adaptiert, die eine Basis für OpenId’s benötigten. OAuth setze sich schnell als Protokoll für die Authorisierung von API Zugriffen durch. Immer noch mangelte es dem Standard an der Möglichkeit der Authentifizierung. Die Erweiterung kam mit OpenID Connect (OIDC), dass OAuth nutzte und um einige Eigenschaften erweiterte. OAuth selber war von vornherein so angelegt, dass es Erweiterungen flexibel zuließ. Somit bot es sich an diese Protokoll als Grundlage zu nutzen.

Durch die Integration des Logins in OAuth wird es möglich, mit demselben Protokoll kombinierte Szenarien, also das Login im Namen des Benutzers und den abgesicherten Zugriff auf dessen Ressourcen, zu implementieren. Mit anderen Worten ich kann endlich sicherstellen, dass nur noch mein Sohn meine Katze versorgt, während ich im Urlaub bin :D.

OpenID Connect wurde am 26. Februar 2014 als Standard der OpenID Foundation verabschiedet und ist bereits von Anbietern wie Google, Microsoft und der Deutschen Telekom implementiert worden.

Backflash

Auch vor der Erfindung von OIDC gab es Möglichkeiten den Zugriff abzusichern. Technich ging es bei den Protokollen hauptsächlich um Single Sign-On (einmaliges Anmelden an unterschiedlichen Anwendungen) oder die Verbindung von Anwendungen unterschiedlicher Anwender auf eine standardisierte Weise. Hierzu wurde OpenID2.0 oder SAML 2.0 eingesetzt. OpenID2.0 hatte erhebliche Einschränkungen bei der Sicherheit. SAML ist ein auf XML basierendes, featurereiches Protokoll, das auch heute noch häufig eingesetzt und von vielen Anwendungen direkt unterstützt wird. Leider hat es den Nachteil aufgrund der verwendeten XML Signaturen und X.509 Zertifikate im Betrieb sehr aufwändig zu sein. Beide Protokolle sind, das ist deren wesentlicher Nachteil, vor der Entwicklung modernen mobile -Apps entstanden und adressieren daher dessen Anforderungen nicht.

new =  cool

Mit dem Siegeszug der coolen mobile Apps kommt OIDC immer mehr zum Einsatz. Die Grundidee von OpenID Connect ist, die Authentifizierung eines Benutzers als eine Erweiterung des OAuth-2.0-Autorisierungsprozesses zu implementieren. Das funktioniert recht einfach, indem man einen OAuth scope nutzt. Für OIDC wurde festgelegt, dass ein OAuth request an einen Authorization Server, der den Scope „openid“ enthält, eine Authentifizierung nach OIDC zur Folge haben muss.

In unserem Schlüssel Beispiel heißt das also, der „Schlüsselwächter“ den Schlüssel nur herausgeben darf, wenn er sich vorher versichert hat, dass die anfordernde Person auch mein Sohn ist. Mit OIDC kann ich sogar mitteilen, wie er das feststellen soll. Der Schlüssel bekommt dann die Information mitgegeben, wer Ihn angefordert und wie er sich ausgewiesen hat. Habe ich meiner Haustür nun gesagt, dass das Schloss sich nur öffnen darf, wenn der Schlüssel passt und er von meinem Sohn angefordert wird, kann ich beruhigt in den Urlaub fahren. Ich vertraue meinem Sohn ja, dass er in meiner Abwesenheit keine Party in meiner Wohnung feiert.

Mit OIDC hat der Eigentümer einer Ressource also die Gewissheit, dass auch nur derjenige Zugang zu freigegebener Ressource erhält, dem er auch vertraut und dem er die Erlaubnis dazu gegeben hat.