GitHub erweitert die Sicherheitsoptionen für OAuth Apps: Anwendungen können kurzlebige Access Tokens mit Refresh Tokens nutzen, bis zu zehn Callback-URIs registrieren und Wildcard-Matching pro Redirect URI steuern. Das reduziert den Zwang zu langlebigen Zugriffstokens und separaten App-Registrierungen für jede Umgebung. Gleichzeitig entstehen neue Migrationsaufgaben. Besonders bestehende Apps mit nur einer Redirect URI können weiterhin ein historisches Wildcard-Verhalten besitzen, das bewusst geprüft werden muss.
Für Unternehmen betrifft die Änderung nicht nur Entwicklerkomfort. OAuth-Tokens öffnen den Zugriff auf GitHub-Ressourcen; Redirect URIs bestimmen, wohin Autorisierungscodes und Nutzer nach dem Login geleitet werden. Fehler in Tokenrotation können Anmeldungen unterbrechen. Zu breite Wildcards können Codes an unerwartete Pfade oder Subdomains senden. Eine sichere Einführung braucht daher Inventar, Tests, schrittweisen Rollout und messbare Rückfallgrenzen.
Was GitHub neu bereitstellt
GitHub OAuth Apps können kurzlebige Access Tokens anfordern. Laut GitHub gilt ein Access Token acht Stunden, der zugehörige Refresh Token sechs Monate. Der Refresh-Vorgang liefert ein neues Tokenpaar. Entwickler können das Verhalten zunächst über den Scope offline_access testen oder in der App-Registrierung generell erzwingen. Neue Apps verwenden kurzlebige Tokens standardmäßig. Bestehende SDKs müssen den Refresh-Flow jedoch technisch unterstützen.
OAuth Apps können außerdem bis zu zehn Callback-URIs registrieren. Das kann getrennte Produktions-, Staging- und regionale Umgebungen innerhalb einer App abbilden. Für OAuth Apps und GitHub Apps lässt sich Wildcard-Matching pro Redirect URI aktivieren. GitHub warnt ausdrücklich vor schwacher Routenkontrolle. Bei Apps mit nur einer Redirect URI ist das frühere Wildcard-Verhalten zunächst sichtbar und aktiv, sofern es nicht abgeschaltet wird.
Please review your apps and disable wildcard matching if you do not need it.
GitHub Changelog
Warum kurzlebige Tokens nicht automatisch sicher sind
Ein acht Stunden gültiger Access Token begrenzt die Zeit, in der ein gestohlenes Token direkt nutzbar ist. Der langlebigere Refresh Token wird dadurch zum besonders schützenswerten Geheimnis. Er gehört verschlüsselt in einen serverseitigen Secret Store, darf nicht in Browser-Storage oder Logs gelangen und benötigt einen klaren Widerrufspfad. Rotation muss atomar umgesetzt werden, damit parallele Anfragen nicht mit einem bereits ersetzten Refresh Token arbeiten.
- Access und Refresh Tokens nie in Anwendungslogs, Fehlerdaten oder Client-Telemetrie schreiben.
- Refresh-Vorgänge serverseitig ausführen und Tokenpaare verschlüsselt sowie mandantentrennt speichern.
- Abgelaufene Tokens sauber von widerrufenen Tokens und Netzwerkfehlern unterscheiden.
- Parallelzugriffe durch Sperre, Version oder Single-Flight-Mechanismus koordinieren.
- Logout, Entzug der Autorisierung und kompromittierte Secrets mit echter Invalidierung testen.
Auch Verfügbarkeit zählt. Wenn Refresh fehlschlägt, darf die Anwendung nicht in einer Endlosschleife neue Anfragen erzeugen oder alte Tokens weiterverwenden. Nutzer brauchen einen verständlichen Weg zur erneuten Autorisierung. Hintergrundjobs müssen ihren Fehlerzustand sichtbar machen. Für kritische Integrationen sollte feststehen, welche Geschäftsprozesse nach acht Stunden ohne erfolgreiche Rotation stoppen und wie der Betrieb informiert wird.
Redirect URIs und Wildcards härten
Mehrere explizite Callback-URIs sind meist sicherer als eine breite Wildcard. Jede registrierte URI sollte genau einer kontrollierten Umgebung und Route entsprechen. Test- und Vorschauumgebungen gehören nur dann in dieselbe App, wenn Berechtigungen, Betreiber und Schutzbedarf wirklich zusammenpassen. Nutzerinhalte, frei wählbare Subdomains oder offene Weiterleitungen im Callback-Pfad erhöhen das Risiko, dass Autorisierungscodes an einen Angreifer gelangen.
- Alle GitHub OAuth Apps und GitHub Apps mit Owner, Zweck und Umgebungen inventarisieren.
- Registrierte Callback-URIs sowie tatsächliche Login-Routen und Weiterleitungen abgleichen.
- Legacy-Wildcards bei Ein-URI-Apps sichtbar prüfen und ohne echten Bedarf deaktivieren.
- Benötigte Umgebungen als exakte URIs registrieren; maximalen Umfang nicht als Zielwert behandeln.
- Manipulierte Hostnamen, Pfade, offene Redirects und nicht kontrollierte Subdomains negativ testen.
Wenn Multi-Tenant-Subdomains eine Wildcard erforderlich machen, braucht die Anwendung strikte Host- und Routenkontrolle. Der Mandant darf die Zielroute nicht beliebig beeinflussen. Callback-Pfade sollten Autorisierungscodes unmittelbar verarbeiten und danach nur auf eine intern erlaubte Zielmenge weiterleiten. State-Parameter, PKCE und Sitzungsbindung bleiben unabhängig von GitHubs neuer Konfiguration wichtig. Wildcard-Matching löst keine Schwäche in der eigenen Callback-Implementierung.
Migrationsplan ohne Login-Ausfall
Der Rollout beginnt mit Telemetrie und SDK-Prüfung. In einer nichtkritischen Umgebung aktiviert das Team offline_access, beobachtet Refresh-Vorgänge und testet Ablauf, Widerruf und parallele Nutzung. Danach folgt ein kleiner Anteil produktiver Nutzer oder eine interne App. Erst wenn Fehlerrate, erneute Logins und Hintergrundjobs stabil sind, kann kurzlebiges Tokenverhalten für die gesamte Registrierung erzwungen werden. Ein Rückfall bleibt zeitlich begrenzt verfügbar.
Parallel wird das Redirect-Inventar bereinigt. Ungenutzte URIs werden entfernt, Wildcards minimiert und Änderungen mit realen Login-Flows getestet. Monitoring sollte fehlgeschlagene Tokenrotation, Callback-Abweisungen, ungewöhnliche Zielhosts und stark steigende Autorisierungen erkennen. Änderungen an Domains, SDKs oder Deployment-Routen gehören künftig in denselben Security-Review. Damit bleibt die Konfiguration nach der einmaligen Migration kontrollierbar.
Fazit
GitHubs neue OAuth-Funktionen ermöglichen eine deutlich bessere Sicherheitsbasis: kurzlebige Access Tokens reduzieren das direkte Missbrauchsfenster, mehrere Callback-URIs ersetzen viele unnötige Wildcards. Der Gewinn entsteht aber erst durch saubere Refresh-Token-Speicherung, kompatible Clients, exakte Redirect-Routen und einen gestuften Rollout. Bestehende Apps mit einer URI sollten das vererbte Wildcard-Matching ausdrücklich prüfen und deaktivieren, wenn es nicht erforderlich ist.