Einfache Authentifizierung und Autorisierung
Mit zunehmender Verbreitung von verteilten Architekturen – vor allem Microservices – steigt auch der Bedarf an Protokollen die Authentifizierung und Autorisierung ermöglichen. Sessions und Cookies, die bei klassischen Webanwendungen oft das Mittel der Wahl waren, können Anforderungen für verteilte Architekturen nicht immer erfüllen. OAuth 2.0 und OpenID Connect (OIDC) helfen Ihnen dabei Ihre Sicherheit im Unternehmen zu verbessern und die Verwaltung von Passwörtern für die Anwender:innen einfacher zu gestalten.
Aber, was können OAuth 2.0 und OpenID Connect und wie unterscheiden sie sich? Auf was müssen Sie achten, wenn Sie diese Protokolle verwenden? Wir zeigen Ihnen, wie Sie diese ganz einfach implementieren, welche Unterschiede es gibt und welche Risiken Sie vermeiden können!
OAuth 2.0 und OpenID Connect Grundlagen
Lästige Anfragen bei Ihrer Technik oder dem Chief Information Security Officer (CISO) und Suchen nach dem Passwort können Sie gekonnt umgehen: OAuth 2.0 und OpenID Connect sorgen dafür, dass die verteilten Anwendungen in einer abgesicherten Umgebung miteinander kommunizieren und Sie selbst nur noch ein Passwort für alle Anwendungen benötigen. Damit wird nicht nur die Passwortverwaltung vereinfacht, sondern Sie sparen auch noch Zeit und Geld und sorgen für mehr Sicherheit im Unternehmen.
- OAuth 2.0 eröffnet die Möglichkeit Dritten Zugriff auf bestimmte Daten oder Dienste zu geben.
- OpenID Connect ermöglicht die Bestätigung der Identität von Nutzer:innen gegenüber Dritten.
Zum verwechseln ähnlich - Und doch ganz anders
Bei Kunden fällt uns immer wieder auf, dass OAuth 2.0 und OpenID Connect synonym verwendet werden. Dabei brauchen sich die zwei Protokolle zwar gegenseitig, aber sie haben unterschiedliche Aufgaben:
- OAuth 2.0 bildet das Autorisierungsprotokoll und ist nicht dafür vorgesehen Identitätsinformationen weiter zu geben. Es beantwortet also die Frage „Was darf ich?“ und beschäftigt sich mit den Berechtigungen eines Users.
- OpenID Connect macht die Authentifizierung und stellt die Frage „Wer bin ich?“. Das Protokoll bildet dazu mit Hilfe von ID Tokens die Identität der Nutzer:innen ab.
OpenID Connect bildet damit die Erweiterung von OAuth 2.0 um Authentifizierungsaspekte.
Sie fragen sich, was das genau bedeutet?
Beides sind standardisierte Protokolle, welche zwischenzeitlich auch in vielen Unternehmen im Einsatz sind. Im Vergleich zu eigenen Ansätzen ist die Fehlerwahrscheinlichkeit erheblich geringer, der Aufwand für alle Beteiligten minimiert sich, sie sind DSGVO konform und die Verfügbarkeit an Frameworks und Bibliotheken für verschiedene Sprachen erleichtert die Implementierung erheblich.
Sie erhalten mit OAuth 2.0 und OpenID Connect also einen standardisierten, einfachen und sicheren Workflow!
Ein Beispiel – „Valet Parking“ vs. „Einchecken im Hotel“
- Mit einem Generalschlüssel lässt sich Ihr Auto öffnen und steuern – Alles ist möglich. Möchten Sie Ihr Auto bei Valet Parking abgeben, verwenden Sie einen zweiten Schlüssel, auf dem Sie bestimmte Eigenschaften festlegen: Sie wollen, dass Ihr Auto nur geparkt wird und niemand Zugriff auf Ihren Kofferraum oder das Handschuhfach hat. Das Personal des Dienstleisters kann somit Ihr Auto bewegen und parken, aber nicht den Kofferraum öffnen. Darüber hinaus kennt das Personal auch nicht Ihren Namen und keine Identitätsinformationen, weil OAuth 2.0 nicht dafür vorgesehen ist, Identitätsinformationen weiterzugeben.
- Gehen Sie in ein Hotel um einzuchecken, benötigt das Personal an der Rezeption Ihre Identität. Hier reicht es nicht, Ihren Autoschlüssel einzureichen, um einen Zimmerschlüssel zu erhalten. Persönliche Daten müssen hinterlegt werden. Diese Authentifizierung übernimmt für Sie im Bereich verteilter Systeme OpenID Connect.
Herausforderungen bei der Einführung von OAuth 2.0 und OpenID Connect
Vor allem die Abstimmung mit vielen verschiedenen Abteilungen, wie beispielsweise dem Datenschutz und dem Fachbereich, können die Implementierung von OAuth 2.0 und OpenID Connect erschweren. Aber auch Verständnisprobleme, was die zwei Protokolle können oder alte bzw. unbekannte Technologien stellen alle Beteiligten vor eine große Herausforderung.
Der Wunsch nach einer eigenen Implementierung ist oft groß, allerdings weichen diese meist stark vom Standard ab. Oft fehlt auch das technische Know-how bei den Entwickler:innen und regulatorische Gegebenheiten von beispielsweise der BaFin hindern Unternehmen sich um solche Single Sign-On (SSO) Lösungen intensiver zu kümmern.
Warum sind ID Tokens so wichtig?
ID Tokens übermitteln bei Autorisierung-Anfragen verschiedene Identititäts- und Autorisierungsinformationen – u. a. Name, Rolle, Scopes – und sind deshalb essentiell für eine Authentifizierung mit Hilfe von OpenID Connect. Sie werden vor allem in verteilten Architekturen angewendet und bilden die Grundlage für das Single Sign-On. ID Tokens können als signierte JSON Web Tokens (JWT) ohne Rückfrage auf Gültigkeit geprüft werden und bei Bedarf gemäß dem JWE-Standard auch verschlüsselt übertragen werden. So machen Sie Ihre Anwenderlandschaft nicht nur sicherer, sondern Nutzer:innen müssen ihre sensiblen persönlichen Daten auch nicht mit anderen Parteien teilen. Und sie können sich mit einem einzigen Passwort an allen Anwendungen anmelden.
Was verbirgt sich hinter Single Sign-On?
Für alle Anwender:innen gibt es gute Neuigkeiten. Und auch die Entwickler:innen freuen sich über eine Single Sign-On (SSO) Lösung. Denn damit lassen sich die Daten der Nutzer:innen, die verstreut in unterschiedlichen Systemen eingegeben sind, sammeln und zu einer Identität zusammenführen – Der Federated Identity. Der User muss sich also nur noch bei einem Identitätsanbieter anmelden und kann diese Anmeldung bei vielen weiteren Diensten nutzen. Dabei werden mit Hilfe von OAuth 2.0 und OIDC definiert, welche Rolle welchen Zugriff auf welche Daten hat.
Der Vorteil: Die ursprünglichen Informationen bleiben stets dort, wo sie eingegeben wurden, da die Federated Identity für einheitliche Datenstandards sorgt und die Informationen bei Bedarf trotzdem geteilt werden können.
IT-Security verbessern mit OAuth 2.0 und OpenID Connect
Verzichten Sie auf komplizierte Eigenlösungen und vereinfachen Sie die Arbeit Ihrer Entwickler:innen sowie das Leben Ihrer Anwender:innen! Verwenden Sie die verbreiteten offenen Standards OAuth 2.0 und OpenID Connect.
Wir helfen Ihnen dabei: Von der Problemerkennung, über die Anforderungsermittlung, der Aufnahme des Ist-Zustands bis hin zur gesamten Implementierung – Wir sind Ihr Ansprechpartner in Sachen IT-Security!
Im Rahmen eines Workshops identifizieren wir zunächst grob welche Anforderungen Sie an Authentifizierung und Autorisierung stellen. Anschließend analysieren wir den Ist-Zustand Ihrer Anwendungslandschaft und Systemarchitektur, um Probleme und weitere Anforderungen zu identifizieren. Abschließend stellen wir Ihnen unter Berücksichtigung der ermittelten Anforderungen Möglichkeiten und Lösungen vor.
- Wir haben jede Menge Erfahrung und beraten Sie gerne bei der Auswahl des Protokolls (OAuth 2.0, OpenID Connect 1.0, Ablösung/Migration von SAMLv2)
- Wir unterstützen und beraten Sie herstellerneutral bei der Auswahl des für Sie geeigneten Identity Providers.
- Wir prüfen Ihre bereits implementierte Lösung auf Standardverträglichkeit und Sicherheit. Bei Auffälligkeiten helfen wir Ihnen gerne weiter.
Sie haben sich bereits für OAuth 2.0 oder OpenID Connect entschieden, sind sich aber nicht ganz sicher, ob Ihre Ansprüche erfüllt werden? Sie möchten ungern viel Zeit investieren um dann festzustellen, dass die geplante Lösung nicht umsetzbar ist?
Wir entwerfen und implementieren für spezielle Szenarien einen technischen Durchstich. Dieser weist die Machbarkeit Ihres Vorhabens exemplarisch nach und schafft Vertrauen in die geplante Umsetzung bei gleichzeitig überschaubaren Kosten.
Um keine falschen Erwartungen zu wecken – Der technische Durchstich, der in diesem Rahmen entwickelt wird, eignet sich nicht für den Produktiveinsatz.
Ob für Entwickler:innen, Architekt:innen, Security-Verantwortliche oder auch den Scrum Master: Mit einer Schulung vor Ort erklären wir Ihnen OAuth 2.0 und OpenID Connect. Der Vorteil: Sie können vorab inhaltliche Wünsche an unsere Trainer:innen richten, mit denen diese eine auf Sie ausgerichtete Schulung erarbeiten.
Niemand liest gerne die zahlreichen technischen Originalspezifikationen für OAuth 2.0 und OpenID Connect im Detail. Wir kennen alle relevanten Spezifikationen dieser Standards und die häufigsten Herausforderungen und Fallstricke dazu. Unsere Schulung kann inhaltlich sowohl als Management-Überblick z. B. für den Product Owner oder als technisches Hands-On Training für Architekt:innen und Entwickler:innen ausgestaltet werden.
Frei kombinierbare Module unseres Trainings umfassen u. a. folgende Themen:
- Einführung in OAuth 2.0 und OpenID Connect
- Authorization Grant Flows: Wann verwende ich welchen?
- Welche Typen von Tokens gibt es und wie unterscheiden sich diese
- Validierung von Tokens
- Implementierung eines OAuth 2.0 und OIDC Resource Servers
- Implementierung von OAuth 2.0 und OIDC Clients (z. B. Angular SPA oder Spring MVC)
- Integration von OAuth 2.0 und OIDC in ein API Gateway
- Fortgeschrittene Konzepte wie Token-Relay oder Token-Exchange
- Aktuelle Entwicklungen rund um OAuth 2.0 und OIDC (Neue Sicherheitsempfehlungen bzw. Best Practices)
Ihre Entwickler:innen stecken in anderen Projekten fest? Wir übernehmen auch die Umsetzung in Ihrer Anwendungen für Sie! Dabei setzen wir, wenn möglich, auf zertifizierte Bibliotheken. Der Vorteil: Nachgewiesene und sichere Funktionsweise bei überschaubarem Aufwand – Wieso das Rad neu erfinden?
Wir stehen Ihnen bei der Implementierung als Sparringspartner zur Verfügung.
Dabei klären wir mit Ihnen zusammen verschiedene Fragen:
- Wo müssen sich Ihre Anwender:innen überall einloggen?
- Löst OAuth 2.0 und OpenID Connect überhaupt Ihr Problem?
- Gibt es bereits einen geplanten Identity Provider, an dem sich Authentifizierung und Autorisierung ausrichten? Ist vielleicht bereits ein Produkt gekauft? Muss das Produkt durch Sie bereitgestellt werden oder wird es durch einen Dienstleister angeboten?
- Benötigen Sie eine Cloud-verträgliche Lösung oder wird die Anwendungslandschaft auf Ihrer Infrastruktur betrieben?
- Gibt es schon konkrete Vorstellungen von einer Zielarchitektur?
- Bedarf es einer Integration in eine bestehende Architektur?
- Müssen andere Authentifizierungs-/Autorisierungsprotokolle integriert werden? Werden Anwendungen mit unterschiedlichen Authentifizierungs-/Autorisierungsprotokollen miteinander interagieren?
