OpenID Connect (OIDC) ist ein Authentifizierungsprotokoll, das auf OAuth 2.0 basiert. Es ermöglicht es Clients (z. B. Web-Apps, Mobile-Apps), die Identität eines Benutzers sicher zu verifizieren, der sich bei einem externen Identitätsanbieter (IdP) anmeldet — zum Beispiel Google, Microsoft, Apple, etc.
OAuth 2.0 → regelt die Autorisierung (Zugriff auf Ressourcen)
OpenID Connect → regelt die Authentifizierung (Wer ist der Benutzer?)
Benutzer klickt auf "Login mit Google"
Deine App leitet den Benutzer zum Google-Login weiter
Nach erfolgreichem Login leitet Google den Benutzer mit einem ID Token zurück
Deine App validiert dieses JWT-Token
Du weißt nun, wer der Benutzer ist – verifiziert von Google
Das ID Token ist ein JSON Web Token (JWT) mit Informationen über den Benutzer, z. B.:
{
"iss": "https://accounts.google.com",
"sub": "1234567890",
"name": "John Doe",
"email": "john@example.com",
"iat": 1650000000,
"exp": 1650003600
}
iss
= Issuer (z. B. Google)
sub
= Benutzer-ID
email
, name
= Benutzerinformationen
iat
, exp
= Zeitstempel
"Login mit Google/Microsoft/Apple"
Single Sign-On (SSO) in Unternehmen
Zentrale Identitätsverwaltung (Keycloak, Auth0, Azure AD)
OAuth-basierte APIs mit Identitätsprüfung
Komponente | Beschreibung |
---|---|
Relying Party | Deine App, die den Login anfordert |
Identity Provider | Der externe Login-Anbieter (z. B. Google) |
ID Token | Das JWT mit den Benutzerinformationen |
UserInfo Endpoint | (Optional) API für weitere Benutzerdaten |
CORS (Cross-Origin Resource Sharing) ist ein Sicherheitsmechanismus, der von Webbrowsern implementiert wird, um zu kontrollieren, welche Webseiten auf Ressourcen von anderen Domains zugreifen dürfen. Standardmäßig blockieren Browser aus Sicherheitsgründen sogenannte Cross-Origin-Anfragen, also Anfragen von einer Webseite an eine andere Domain, ein anderes Protokoll oder einen anderen Port.
Ohne CORS könnten bösartige Webseiten im Hintergrund Anfragen an andere Server senden (z. B. API-Server oder Banking-Seiten), wodurch sensible Daten gestohlen oder missbraucht werden könnten (Cross-Site Request Forgery, CSRF). CORS sorgt dafür, dass nur explizit erlaubte Webseiten auf Ressourcen zugreifen dürfen.
Wenn eine Webanwendung eine Cross-Origin-Anfrage stellt (z. B. von http://example.com
an https://api.example.com
), sendet der Browser automatisch eine CORS-Anfrage. Der Server kann dann in den HTTP-Headern antworten, ob die Anfrage erlaubt ist:
Ohne CORS-Header:
Der Browser blockiert die Anfrage.
Mit CORS-Headern:
Der Server kann mit Access-Control-Allow-Origin: *
(alle Domains) oder einer bestimmten Domain (Access-Control-Allow-Origin: https://example.com
) antworten. Damit wird der Zugriff erlaubt.
Für einige Anfragen (z. B. mit PUT
, DELETE
, speziellen Headern) führt der Browser einen Preflight-Request mit der OPTIONS
-Methode aus. Der Server muss dann mit den richtigen CORS-Headern antworten, um die Hauptanfrage zu ermöglichen.
CORS ist eine wichtige Sicherheitsmaßnahme, die verhindert, dass unerlaubte Webseiten auf fremde Ressourcen zugreifen. Entwickler müssen serverseitig die richtigen Header setzen, um den Zugriff für legitime Clients zu erlauben.
Obfuscation ist ein Prozess, bei dem der Quellcode eines Programms so verändert wird, dass er für Menschen schwer zu verstehen ist, während er seine Funktionalität beibehält. Dies wird oft angewendet, um den Quellcode vor Reverse Engineering zu schützen oder um ihn kompakter zu machen, ohne die Funktionalität zu beeinträchtigen. Dabei werden Techniken wie das Umbenennen von Variablen und Funktionen, das Hinzufügen von unnötigem Code oder das Verändern der Programmstruktur verwendet. Obfuscation wird häufig in der Softwareentwicklung eingesetzt, insbesondere bei der Entwicklung von kommerziellen Softwareprodukten oder bei der Bereitstellung von Software als Service (SaaS), um das geistige Eigentum zu schützen und unerwünschte Manipulationen zu erschweren.