SECURAM IT-Security-Glossar

Definition:

Authorization Server – Definition und Bedeutung

Ein Authorization Server (deutsch: Autorisierungsserver) ist die zentrale Instanz in OAuth 2.0 und OpenID Connect (OIDC). Er authentifiziert Nutzer und Clients, erteilt Autorisierungen und stellt Token aus (Access-Token, Refresh-Token und – bei OIDC – ID-Token). Er dient der entkoppelten, standardkonformen Zugriffskontrolle zwischen Anwendungen und APIs. In OIDC entspricht er dem OpenID Provider (OP). [Q1][Q3][Q4]

Hintergrund und Entstehung

Der Begriff Authorization Server stammt aus dem OAuth 2.0 Authorization Framework (RFC 6749). Dort wird der Authorization Server als die Komponente beschrieben, die nach erfolgreicher Authentifizierung und Autorisierung Access-Token an Clients ausgibt und damit den Zugriff auf Ressourcen ermöglicht. Ziel war, Autorisierung von der Ressource zu trennen und standardisiert über klar definierte Flows abzubilden. [Q1]

OpenID Connect hat OAuth 2.0 um eine Identitätsschicht ergänzt. Der Authorization Server fungiert hier als OpenID Provider, signiert ID-Token (JWT) und stellt Claims über den Endnutzer bereit. Damit können Clients die Identität der Nutzer verifizieren und Single Sign-on (SSO) über verschiedene Anwendungen hinweg umsetzen. [Q4]

Mit RFC 8414 wurde die Beschreibung von Authorization-Server-Metadaten standardisiert. Über eine .well-known-Adresse können Clients Endpunkte (zum Beispiel Authorization-, Token-, Introspection- und Revocation-Endpoint) und Fähigkeiten des Servers automatisiert entdecken. Das erhöht die Interoperabilität und reduziert Konfigurationsfehler. [Q3]

Wichtigste Merkmale und Kernelemente

Standardisierte Endpunkte: Ein Authorization Server stellt unter anderem die Endpunkte /authorize und /token bereit. Optional kommen Introspection- und Revocation-Endpunkte hinzu. Diese sind in OAuth 2.0 definiert und können per Metadata Discovery veröffentlicht werden. [Q1][Q3]

Token-Ausgabe und -Arten: Er generiert Access-Token für API-Zugriffe, Refresh-Token zur Erneuerung von Sitzungen und in OIDC zusätzlich ID-Token zur Identitätsübermittlung. Format, Lebensdauer und Signatur folgen den jeweiligen Profilempfehlungen und Sicherheitsrichtlinien. [Q1][Q4]

Sicherheits-Best-Practices: Moderne Authorization Server setzen den Authorization-Code-Flow mit PKCE ein, verzichten auf den Implicit Flow, prüfen Redirect-URIs strikt und begrenzen Token-Lebensdauern. Wo passend kommen Proof-of-Possession-Mechanismen wie DPoP oder MTLS hinzu. Die OAuth 2.0 Security Best Current Practice (RFC 9700) und RFC 8252 für Native Apps aktualisieren die Empfehlungen und stufen unsichere Modi als veraltet ein. [Q5][Q6]

Discovery und Interoperabilität: RFC 8414 definiert, wie Clients Fähigkeiten und Endpunkte des Authorization Servers maschinenlesbar beziehen. OIDC Discovery erweitert dies um Identitätsfunktionen. [Q3][Q4]

Scopes, Policies und Consent: Der Authorization Server verwaltet Scopes und Richtlinien, erzwingt Benutzerzustimmungen (Consent) und kann Risiko- oder Kontextprüfungen (zum Beispiel MFA-Anforderungen) durchführen. Damit unterstützt er den Aufbau von Zero-Trust-Architekturen. [Q1][Q6]

Bedeutung des Authorization Servers für Unternehmen

Unternehmen im DACH-Raum nutzen den Authorization Server als zentrale Kontroll- und Vertrauensinstanz ihrer IAM-Architektur. Er ermöglicht konsistente Richtlinien, nachvollziehbare Audits und die Delegation von Zugriffen über Systemgrenzen hinweg – etwa für Cloud-Dienste, Partner-APIs und Microservices. [Q1][Q4]

Aus Sicht des Bundesamts für Sicherheit in der Informationstechnik (BSI) unterstützt ein zentraler Autorisierungsdienst die Umsetzung von Identitäts- und Berechtigungsmanagement gemäß IT-Grundschutz, insbesondere dem Baustein ORP.4 und den zugehörigen Umsetzungshinweisen. So lassen sich organisatorische und technische Maßnahmen wie Rollen, Rechte und Protokollierung systematisch etablieren. [Q7]

In der Praxis zeigt sich, dass Unternehmen, die frühzeitig auf eine konsolidierte Architektur mit OIDC und OAuth 2.0 setzen, Integrationsaufwände reduzieren, SSO-Mechanismen vereinheitlichen und Fehlkonfigurationen bei API-Zugriffen verringern. Gap-Analysen gegenüber RFC- und BSI-Vorgaben können die Einführung zusätzlich beschleunigen.

Abgrenzung zu verwandten Begriffen

Authorization Server vs. Identity Provider (IdP): In OpenID Connect ist der Authorization Server typischerweise der OpenID Provider (eine Form des IdP), der zusätzlich ID-Token bereitstellt. Ein reiner OAuth 2.0 Authorization Server autorisiert Zugriffe, ohne notwendigerweise Identitätsinformationen offenzulegen. [Q4]

Authorization Server vs. Resource Server: Der Resource Server hostet die geschützte API und prüft übermittelte Token. Der Authorization Server stellt diese Token aus, bewertet Policies und trifft Autorisierungsentscheidungen. Beide Rollen können in getrennten Systemen oder in einem Produkt umgesetzt werden. [Q1]

Beispiele aus der Praxis

Beispiel 1 (fiktiv): Energieversorger (≈1.200 Mitarbeitende)

Ein Energieversorger mit rund 1.200 Mitarbeitenden migriert von historisch gewachsenen SSO-Lösungen zu einer zentralen OIDC-Architektur mit einem Authorization Server. Ergebnis: deutlich weniger Supporttickets zu Login- und Token-Fehlern sowie konsistente MFA-Policies für zahlreiche Fachanwendungen innerhalb weniger Monate.

Beispiel 2 (fiktiv): Healthcare-Plattform (≈200 Mitarbeitende)

Eine Healthcare-Plattform mit rund 200 Mitarbeitenden führt den Authorization-Code-Flow mit PKCE für Mobile-Apps ein und ersetzt proprietäre Token-Mechanismen. Ergebnis: Die mittlere Behebungszeit (MTTR) bei Authentifizierungsincidenten sinkt spürbar, und die Onboarding-Zeit für Partner-APIs verkürzt sich deutlich.

Häufig gestellte Fragen

Was macht ein Authorization Server?

Ein Authorization Server authentifiziert Benutzer oder Clients, prüft Berechtigungen und stellt Access- und Refresh-Token sowie bei OIDC ID-Token aus. Außerdem bietet er definierte Endpunkte wie /authorize und /token und veröffentlicht seine Konfiguration über Metadata-Discovery-Dokumente. [Q1][Q3][Q4]

Ist der Authorization Server ein Identity Provider?

In OpenID Connect agiert der Authorization Server als OpenID Provider und liefert ID-Token, erfüllt also eine Identity-Provider-Funktion. In reinem OAuth 2.0 kann er ohne Identitätsclaims arbeiten und ausschließlich Autorisierungsentscheidungen treffen. [Q4][Q1]

Welche Endpunkte hat ein Authorization Server?

Kernendpunkte sind /authorize und /token. Häufig kommen /introspect, /revoke und eine /.well-known/-Discovery-Ressource hinzu. Details und Parameter legt RFC 6749 fest, RFC 8414 beschreibt die maschinenlesbaren Metadaten. [Q1][Q3]

Welche Sicherheits-Best-Practices gelten aktuell?

Empfohlen sind der Authorization-Code-Flow mit PKCE, der Verzicht auf den Implicit Flow, strikte Redirect-URI-Prüfung und kurze Token-Lebensdauern. Wo sinnvoll werden zusätzliche Schutzmechanismen wie DPoP oder MTLS eingesetzt. Die wichtigsten Vorgaben sind in der OAuth 2.0 Security Best Current Practice (RFC 9700) und in RFC 8252 für Native Apps beschrieben. [Q5][Q6]