- 1 Abschnitt
- 6 Lektionen
- Um den Kurs in deinem Profil zu hinterlegen klicke oben auf Starten
alles ausklappenalles einklappen
Autorisierungsframeworks und -protokolle
Moderne IT-Systeme nutzen verschiedene Autorisierungsframeworks und -protokolle, um den Zugriff auf Ressourcen zu verwalten und die Sicherheit zu gewährleisten. Diese Frameworks und Protokolle bieten standardisierte Methoden zur Autorisierung und sind in vielen Anwendungen und Diensten weit verbreitet.
OAuth 2.0
Grundprinzipien:
- OAuth 2.0 ist ein Autorisierungsframework, das Benutzern ermöglicht, einer Anwendung Zugriff auf ihre Ressourcen zu gewähren, ohne ihre Anmeldedaten preiszugeben.
- Es arbeitet mit Access Tokens, die temporären Zugriff auf Ressourcen bieten.
Hauptflüsse (Flows):
Authorization Code Flow:
- Wird häufig für serverseitige Anwendungen verwendet.
- Der Benutzer authentifiziert sich bei einem Autorisierungsserver, der einen Autorisierungscode an die Anwendung zurückgibt. Die Anwendung tauscht diesen Code gegen ein Access Token aus.
Implicit Flow:
- Geeignet für clientseitige Anwendungen (z.B. Single-Page-Apps).
- Der Benutzer erhält direkt ein Access Token, ohne dass ein Autorisierungscode verwendet wird.
Resource Owner Password Credentials Flow:
- Der Benutzer gibt seine Anmeldedaten direkt an die Anwendung weiter.
- Diese Methode sollte nur in vertrauenswürdigen Umgebungen verwendet werden.
Client Credentials Flow:
- Wird für maschinelle Authentifizierung verwendet (z.B. zwischen Servern).
- Die Anwendung authentifiziert sich selbst beim Autorisierungsserver, um ein Access Token zu erhalten.
Beispiel für einen Authorization Code Flow:
Benutzeranfrage:
- Der Benutzer klickt auf „Login with OAuth“.
Autorisierungsanfrage:
- Die Anwendung leitet den Benutzer zum Autorisierungsserver weiter.
- URL:
https://auth.example.com/authorize?response_type=code&client_id=123&redirect_uri=https://app.example.com/callback
Autorisierungscode:
- Nach erfolgreicher Authentifizierung erhält die Anwendung einen Autorisierungscode.
- Beispiel:
https://app.example.com/callback?code=abc123
Token-Anfrage:
- Die Anwendung tauscht den Autorisierungscode gegen ein Access Token aus.
- Anfrage an den Token-Endpunkt:
https://auth.example.com/token
Token-Antwort:
- Der Autorisierungsserver gibt ein Access Token zurück.
- Beispiel:
{ "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...", "token_type": "Bearer", "expires_in": 3600 }
OpenID Connect
Grundprinzipien:
- OpenID Connect erweitert OAuth 2.0 um Authentifizierungsfunktionen.
- Es fügt ein ID Token hinzu, das Informationen über den Benutzer enthält.
ID Token:
- Ein JWT (JSON Web Token), das Informationen wie die Benutzer-ID, Ausstellungszeit und Ablaufzeit enthält.
- Beispiel für ein ID Token:
eyJhbGciOiJSUzI1NiIsImtpZCI6IjI1NzhiMTc4LWNjMjgtNGFkZS1iYWZiLTVhY2RmMmFmNWI4MyJ9.eyJhdWQiOiI2MjU1NzA2NDgxNzU0NDciLCJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.HcQw0XtDF90YV2YJzP6hyEYvWu8Nxg4ivD6x67r_0Qo
Vorteile:
- Vereinfachte Benutzeranmeldung über verschiedene Anwendungen hinweg.
- Einfache Integration mit OAuth 2.0.
SAML (Security Assertion Markup Language)
Grundprinzipien:
- SAML ist ein XML-basiertes Framework für den Austausch von Authentifizierungs- und Autorisierungsinformationen zwischen Identitätsanbietern und Dienstanbietern.
- Es ermöglicht Single Sign-On (SSO) für Webanwendungen.
SAML-Ablauf:
Anmeldung:
- Der Benutzer versucht, auf eine Anwendung (Dienstanbieter) zuzugreifen.
Umleitung zum Identitätsanbieter:
- Der Dienstanbieter leitet den Benutzer zum Identitätsanbieter zur Authentifizierung weiter.
Authentifizierung:
- Der Benutzer authentifiziert sich beim Identitätsanbieter.
SAML-Antwort:
- Der Identitätsanbieter sendet eine SAML-Antwort mit einer Assertion an den Dienstanbieter.
Zugriff:
- Der Dienstanbieter gewährt dem Benutzer Zugriff basierend auf der SAML-Assertion.
Beispiel einer SAML-Assertion:
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_c1c94018b2d76d09f7e5b8f2e7e43f92" IssueInstant="2021-04-07T12:34:56.789Z" Version="2.0">
<saml:Issuer>https://idp.example.com</saml:Issuer>
<saml:Subject>
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">john.doe@example.com</saml:NameID>
<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConfirmationData InResponseTo="_56f16a34-78e3-4bb8-a2b4-5555a1b2a654" Recipient="https://sp.example.com/SAML2/SSO/POST" NotOnOrAfter="2021-04-07T12:39:56.789Z"/>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions NotBefore="2021-04-07T12:34:56.789Z" NotOnOrAfter="2021-04-07T12:39:56.789Z">
<saml:AudienceRestriction>
<saml:Audience>https://sp.example.com</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>
<saml:AuthnStatement AuthnInstant="2021-04-07T12:34:56.789Z" SessionIndex="_c1c94018b2d76d09f7e5b8f2e7e43f92">
<saml:AuthnContext>
<saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
</saml:Assertion>
Vergleich der Autorisierungsframeworks und -protokolle
| Framework/Protokoll | Beschreibung | Vorteile | Nachteile |
|---|---|---|---|
| OAuth 2.0 | Autorisierungsframework, das Access Tokens zur Ressourcenzugriffskontrolle verwendet | Flexibel, weit verbreitet, unterstützt verschiedene Flows | Erfordert zusätzliche Infrastruktur, kann komplex sein |
| OpenID Connect | Erweiterung von OAuth 2.0 um Authentifizierungsfunktionen | Unterstützt Single Sign-On, einfache Integration mit OAuth 2.0 | Erfordert zusätzliche Implementierung, Sicherheit hängt von der korrekten Nutzung der Tokens ab |
| SAML | XML-basiertes Framework für den Austausch von Authentifizierungs- und Autorisierungsinformationen | Unterstützt Single Sign-On, gut für Unternehmensanwendungen geeignet | Komplexe Implementierung, kann bei großen XML-Nachrichten langsam sein |
