Ein Authorization Server stellt ein Access Token aus, das ein Resource Server unter definierten Bedingungen akzeptiert. Der Client kann nach delegierter Autorisierung für einen Benutzer handeln oder in einem Machine-to-Machine-Flow in eigenem Namen.
OAuth definiert Rollen und Protokollflüsse statt eines Token-Formats oder universellen Berechtigungsmodells. Für benutzerorientierte Anwendungen favorisiert die aktuelle Sicherheitspraxis den Authorization-Code-Flow mit Proof Key for Code Exchange (PKCE). Implementierungen müssen Antworten an den korrekten Client und die Redirect-URI binden, Authorization Codes und Refresh Tokens schützen und sicherstellen, dass Access Tokens nur von ihren vorgesehenen Resource Servern akzeptiert werden.
Wichtigste Punkte
KernrollenResource Owner, Client, Authorization Server und Resource Server unterscheiden; dokumentieren, wenn eine Komponente mehr als eine Rolle übernimmt.
Token-KontrollenAudience, Scope, Lebensdauer und Speicherung einschränken; Tokens vollständig validieren; Refresh Tokens wo angemessen rotieren oder widerrufen; Bearer Tokens nicht in URLs oder Logs exponieren.
Aktuelle Flow-WahlDer OAuth-Security-Best-Current-Practice folgen: Clients sollten den Implicit Grant nur nutzen, wo seine spezifizierten Injektions- und Leckagerisiken gemindert sind, und dürfen den Resource-Owner-Password-Credentials-Grant nicht verwenden.
Wichtige EinschränkungOAuth 2.0 definiert keine Benutzerauthentifizierung und beweist nicht, wer ein Access Token verwendet. Ein gültiges Token ersetzt auch nicht die objekt-, funktions- oder transaktionsebene Autorisierung innerhalb des Resource Servers.