Auth selbst zu bauen ist verlockend, und fast immer eine schlechte Idee, wegen der vielen unsichtbaren Edge Cases.
Nicht weil Entwicklerteams inkompetent waeren, sondern weil Auth viele Edge Cases hat, die erst unter realen Angriffsbedingungen sichtbar werden: Brute-Force-Schutz, Token-Rotation, Logout-Mechanismen, Session-Invalidierung. Fuer die meisten Projekte lohnt sich ein etablierter Auth-Provider wie Keycloak, Auth0, Supabase Auth oder Authentik, die diese Probleme seit Jahren geloest haben.
OAuth2 gegen OIDC
OAuth2 ist ein Autorisierungs-Protokoll, es beantwortet, ob eine App etwas im Namen eines Nutzers tun darf, liefert aber keine standardisierte Nutzerinformation. OpenID Connect ergaenzt OAuth2 um eine Identitaetsschicht und beantwortet, wer der Nutzer eigentlich ist, ueber ein standardisiertes ID Token. Fuer Login-Szenarien braucht es also OIDC, nicht nur OAuth2.
Die wichtigsten Flows
Der Authorization Code Flow mit PKCE ist Standard fuer Web-Apps und Single-Page-Applications, der Nutzer wird zum Auth-Provider weitergeleitet und kehrt mit einem Code zurueck, der gegen ein Token getauscht wird, PKCE ist fuer oeffentliche Clients Pflicht. Der Client Credentials Flow eignet sich fuer Machine-zu-Machine-Kommunikation ohne Nutzerkontext. Der Device Code Flow ist fuer Geraete ohne Browser gedacht, etwa IoT oder Smart TVs.
Token-Management
Access Tokens sollten eine kurze Lebensdauer haben, ergaenzt um Refresh Tokens fuer die Erneuerung, idealerweise mit Refresh Token Rotation als zusaetzlichem Sicherheitsmechanismus.
Checkliste: OIDC statt reinem OAuth2 fuer Login-Szenarien, Authorization Code Flow mit PKCE fuer Web und Mobile, Token-Lebensdauer sinnvoll konfiguriert, Refresh Token Rotation aktiviert, Logout-Mechanismus implementiert, etablierter Auth-Provider statt Eigenbau.
Ein Beispiel aus der Praxis
Ein internes Projekt entschied sich, ein eigenes, vereinfachtes Login-System zu bauen, um Zeit zu sparen. Monate spaeter zeigte ein externer Sicherheitstest mehrere Schwachstellen, unter anderem eine fehlende Begrenzung fuer fehlgeschlagene Login-Versuche, die Brute-Force-Angriffe erleichterte. Die nachtraegliche Migration auf einen etablierten Auth-Provider dauerte laenger als der urspruengliche Eigenbau, behob aber gleichzeitig eine ganze Reihe von Problemen, die im eigenen System erst einzeln haetten entdeckt und gefixt werden muessen.
Auth-Integration fuer euer Projekt? markom.digital integriert OAuth2- und OIDC-Provider in Web- und App-Projekte, sicher, sauber, getestet.
