Loading content
OAuth 2.0 ermöglicht Anwendungen, auf Ressourcen von Benutzern zuzugreifen, ohne ihre Anmeldedaten preiszugeben. Es ist ein flexibles und sicheres Verfahren, das in vielen modernen Webanwendungen eingesetzt wird.
Nutze diesen Steckbrief, um den Baustein kurz zu verstehen, ihn im Modell einzuordnen und bei Bedarf in die 360°-Bewertung zu wechseln.
Technischer Baustein: kann automatisiert, integriert oder betrieben werden.
Konkretes Rädchen im System, das in größeren Zusammenhängen wirkt.
OAuth 2.0 ist ein Autorisierungsstandard, der delegierten Zugriff über Tokens ermöglicht: Eine Client-Anwendung holt Berechtigungen bei einem Authorization Server ein und nutzt die daraus entstehenden Tokens, um beim Resource Server auf geschützte Ressourcen zuzugreifen.
OAuth 2.0 wurde als standardisierter Rahmen für Autorisierung in modernen Anwendungen entwickelt und in der IETF im „OAuth Working Group“-Umfeld spezifiziert. Der formale Kern ist die Veröffentlichung RFC 6749 („OAuth 2.0 Authorization Framework“), die Basis für die beschriebenen Authorization-Flow-Varianten ist (für Web-, Desktop-, Mobile- und Geräte-ähnliche Clients). Ausgangspunkt ist dabei, Anwendungen den Zugriff auf Nutzerressourcen zu ermöglichen, ohne dass Clients Nutzeranmeldedaten herausgeben müssen; der Standard deckt diese Delegation über definierte Rollen, Grants und Token-Lebenszyklen ab.
Denk an OAuth 2.0 als „Berechtigungskette mit Token-Übergabe“: Zuerst wird die Autorisierung angestoßen (Client → Authorization Server). Danach wird das Ergebnis als Grant in einen Token-Status übersetzt (Token-Endpunkt). Anschließend darf der Client beim Resource Server nur mit den akzeptierten Tokens handeln. Wenn ein Access Token abläuft, entscheidet die gewählte Flow-Variante über einen erneuten Grant-/Token-Zugriff (z. B. per Refresh Token) oder über eine erneute Autorisierung über den Authorization Server.
Die Anwendung, die Berechtigungen anfordert und anschließend Tokens als „Ausweis“ beim Resource Server verwendet.
Der Dienst, der Autorisierungsentscheidungen koordiniert, Grants ausgibt und Tokens am Token-Endpunkt bereitstellt bzw. validiert (je nach Flow inkl. Client-Authentifizierung).
Die API-/Ressourcenkomponente, die Tokens entgegennimmt und anhand der Token-Mechanik die Ausführung geschützter Operationen erlaubt oder verweigert.
OAuth 2.0 trennt das Autorisierungsergebnis vom Token-Erwerb: Erst der Token-Schritt macht den Zugriff technisch ausführbar.
Scopes legen fest, welche Ressourcen/Operationen ein Token abdecken soll; damit wird die Autorisierungsentscheidung in Token-Berechtigungen abgebildet.
Die konkrete Ablaufvariante bestimmt, wie der Client den Autorisierungsprozess anstößt, wie der Grant entsteht und wie anschließend Tokens ausgetauscht werden.
Hilfreich ist OAuth 2.0, wenn ein System delegierte API-Zugriffe ermöglichen soll, ohne dass der Resource Server die Client-Nutzeranmeldung direkt „mitführen“ muss—insbesondere bei der Auswahl eines passenden Authorization Flows, bei der Scope-Modellierung und beim Design des Token-Lebenszyklus (z. B. Refresh vs. erneute Autorisierung). Grenzen/Trade-offs: OAuth 2.0 ist primär Autorisierung, nicht ein vollständiges Login-/Identitätsprotokoll—für Nutzer-Authentifizierung wird häufig ein ergänzendes Identitätsprotokoll benötigt. Außerdem gilt das verbreitete „keine Credential-Weitergabe“-Narrativ nicht universell: Der Spezifikationskatalog enthält auch „Legacy: Password Grant“, wodurch credential-nahe Interaktionen in bestimmten (legacy) Entscheidungen vorkommen können.
Wo dieser Baustein im Themenmodell verortet ist.
Keine Strukturpfade verfügbar.
Erkunde, wie dieser Wissensbaustein mit Konzepten, Methoden, Technologien und Tools verbunden ist.
Diese Quellen belegen den Begriff und seine fachliche Bedeutung.
Alle direkten Verbindungen des aktuellen Wissensbausteins in einer kompakten, textuellen Darstellung.
Diese Einordnung zeigt, in welchem Kontext der Baustein typischerweise relevant wird, wie anspruchsvoll er ist und welche Wirkung er im Modell hat.
Die Ebene innerhalb der Organisation (Unternehmen, Domäne, Team), auf der der AssetBlock angewendet wird.