GitHub erlaubt mehrere Redirect-URIs und rotierende OAuth-Tokens

Ein Release-Paket für mehr OAuth-Sicherheit

GitHub hat sein OAuth-App- und GitHub-App-Fundament in einem einzigen Zug modernisiert: mehrere Redirect-Ziele pro App, eine sichtbare Wildcard-Kontrolle und optional ablaufende Zugriffs- sowie Refresh-Tokens. Nachzulesen ist das im Changelog-Eintrag vom 14. August 2026, in dem es heißt: „We’ve released multiple updates to the OAuth app and GitHub App platforms to support more secure app development.“ Drei Sätze weiter listet GitHub die konkreten Bausteine auf, und alle drei berühren Reibungspunkte, mit denen App-Teams seit Jahren leben mussten.

Wer schon einmal eine OAuth-Integration für mehrere Umgebungen gebaut hat, kennt das Muster: ein Redirect-URI-Feld, drei Umgebungen, also drei App-Registrierungen mit drei Client-Secrets, die irgendjemand im Team pflegen muss. Wildcard-Matching lief bisher unsichtbar im Hintergrund mit, ohne dass jemand es bewusst aktiviert hätte. Und Access-Tokens lebten schlicht ewig, solange niemand sie manuell widerrief. GitHub OAuth Refresh Tokens setzen an genau diesen drei Stellen an, ohne bestehende Integrationen sofort zu brechen.

Ehrlich gesagt ist an keiner der drei Änderungen etwas Revolutionäres. Multiple Redirect-URIs, kontrollierbares Wildcard-Matching und ablaufende Tokens mit Refresh-Flow sind Standardkost bei praktisch jedem anderen großen OAuth-Anbieter. Bemerkenswert ist eher, dass GitHub das jetzt alles gleichzeitig nachzieht und dabei bewusst opt-in statt Zwangsumstellung wählt. Das nimmt Druck aus dem Rollout, verschiebt die eigentliche Arbeit aber auch nicht wirklich weg von den Entwicklerteams.

Wer die drei Bausteine getrennt betrachtet, unterschätzt leicht, wie sehr sie sich in der Praxis überlappen. Eine App mit mehreren Redirect-URIs braucht fast automatisch eine bewusste Entscheidung über Wildcard-Matching pro URI. Und wer ohnehin an der Token-Verwaltung schraubt, weil der Refresh-Flow eingebaut wird, sollte die Redirect-Konfiguration gleich im selben Durchgang mitprüfen, statt drei getrennte Wartungsfenster einzuplanen.

Mehrere Redirect-URIs lösen alte App-Duplikate ab

Der praktischste Teil des Updates dürfte für viele Teams die Möglichkeit sein, bis zu zehn Redirect-URIs pro App zu registrieren. Im Originaltext klingt das unspektakulär: OAuth-Apps können jetzt mehrere Redirect-URIs registrieren, um verschiedene Umgebungen, Domains oder Deployment-Konfigurationen zu unterstützen, ohne dafür separate Apps anlegen zu müssen. In der Praxis heißt das: ein Client-ID/Secret-Paar für Entwicklung, Staging und Produktion, statt drei getrennter App-Registrierungen mit jeweils eigenem Rotationsplan.

Technisch findet sich dafür in den Anwendungseinstellungen ein neuer „Add redirect URI“-Button, über den zusätzliche URLs zum Abgleich hinzugefügt werden können. Wer bisher mit Umgebungsvariablen und mehreren registrierten Apps jongliert hat, um denselben OAuth-Flow für lokale Entwicklung und Produktion zu testen, kann diesen Umweg jetzt einsparen. Das reduziert nicht nur Verwaltungsaufwand, sondern auch die Angriffsfläche: weniger registrierte Apps bedeuten weniger Client-Secrets, die im Umlauf sind und im schlimmsten Fall geleakt werden können.

Wer sich fragt, wie GitHub mit ähnlichen Governance-Fragen bei automatisierten Zugriffen umgeht, findet in unserer Einordnung der öffentlichen Vorschau zu Agenten-Governance und offenen Automation-Issues weiteren Kontext dazu, wie GitHub Zugriffsrechte für automatisierte Clients strukturiert. Die Mechanik ist verwandt: Je klarer die Grenzen einer Integration definiert sind, desto weniger Spielraum bleibt für versehentliche Rechteausweitung.

Ein Wermutstropfen bleibt die Obergrenze von zehn Redirect-URIs. Für die überwiegende Mehrheit der Apps ist das mehr als genug, aber Teams mit sehr granularen Multi-Tenant-Setups mit dutzenden Subdomains werden vermutlich trotzdem auf Wildcard-Matching zurückgreifen müssen — und landen damit direkt beim nächsten Thema dieses Updates.

Wildcard-Matching macht ein verstecktes Verhalten sichtbar

Der Absatz, der beim Lesen des Changelogs am meisten Aufmerksamkeit verdient, ist unscheinbar in ein Zitat verpackt: Apps mit nur einer registrierten Redirect-URI hatten Wildcard-Matching bereits aktiviert — als Legacy-Verhalten, das laut GitHub jetzt erstmals sichtbar und kontrollierbar wird. Das betrifft praktisch jede ältere OAuth-App und jede GitHub App, die jemals mit nur einer einzigen Redirect-URI registriert wurde. Wer sein App-Setup seit Jahren nicht mehr angesehen hat, sollte das jetzt nachholen.

Aktiviertes Wildcard-Matching bedeutet konkret: GitHub akzeptiert nicht nur die exakt registrierte Redirect-URI, sondern auch Subdomains und zusätzliche Pfade darunter. Für Multi-Tenant-Architekturen mit vielen Kunden-Subdomains ist das ein praktisches Feature, weil nicht jede Subdomain einzeln registriert werden muss. Für alle anderen ist es ein zusätzlicher, bisher unsichtbarer Vertrauensbereich, der jetzt endlich in den App-Einstellungen einsehbar und einzeln abschaltbar ist.

Nach Jahren mit einem Ein-Redirect-URI-Setup war den meisten Entwicklerteams schlicht nicht bewusst, dass sie überhaupt Wildcard-Matching nutzen. GitHub OAuth Refresh Tokens machen dieses Legacy-Verhalten zum ersten Mal auditierbar, statt es weiter unsichtbar im Hintergrund laufen zu lassen — ein handfester Sicherheitsgewinn, auch wenn er sich zunächst nur wie eine kosmetische Einstellungsänderung liest.

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellseedream_v4_5; quality=high; 5120x2880PromptA pair of distinct blank keys is exchanged between two protected return paths beside a small hourglass, using only unmarked physical objects and clean light, no words, no letters, no numbers, no labels, no panels, no device bay, no logos, no screens, no interface, photorealistic editorial style. A tight documentary composition emphasizes hands-on consequences in a fully text-free scene with blank surfaces and no legible markings. Photorealistic style image. Mood: practical, focused, and investigative. Avoid: watermark, signature, blurry, low quality, distorted, deformed.

Kurzlebige Tokens verändern den Sitzungszustand

Der technisch anspruchsvollste Teil des Updates betrifft den Lebenszyklus der Tokens selbst. Opt-in-Apps erhalten künftig einen Access-Token, der acht Stunden gültig ist, und einen Refresh-Token, der sechs Monate hält. Läuft der Access-Token ab, tauscht die App ihn über den Refresh-Token gegen ein neues Token-Paar — ganz ohne erneute Nutzerinteraktion, solange der Refresh-Token noch gültig ist.

Für Backends, die bisher einen einzigen, unbegrenzt gültigen Access-Token in der Datenbank abgelegt und nie wieder angefasst haben, ist das ein echter Architekturwechsel. Es braucht jetzt eine Logik, die abgelaufene Tokens erkennt, den Refresh-Flow auslöst und das neue Token-Paar persistiert, bevor der nächste API-Call fehlschlägt. Wer diese Logik nicht einbaut, bekommt nach acht Stunden plötzlich 401-Fehler von Nutzern gemeldet, die vorher monatelang klaglos eingeloggt waren.

Die gute Nachricht: Ein sechs Monate gültiger Refresh-Token ist großzügig genug, dass ein einmal korrekt implementierter Refresh-Zyklus für die meisten Anwendungsfälle unauffällig im Hintergrund läuft. Die schlechte Nachricht: „einmal korrekt implementiert“ ist die Bedingung, an der in der Praxis viele Integrationen zunächst scheitern, weil Fehlerbehandlung für abgelaufene Tokens historisch selten priorisiert wurde.

Zwei Fehlerquellen tauchen dabei erfahrungsgemäß am häufigsten auf: Erstens vergisst mancher Client, den neuen Refresh-Token aus der Antwort zu speichern, weil er davon ausgeht, der alte bleibe gültig — genau das ist bei diesem Flow aber nicht garantiert. Zweitens fehlt oft ein Retry mit Backoff für den seltenen Fall, dass der Refresh-Call selbst kurz scheitert, etwa wegen eines Netzwerkfehlers. Beide Lücken lassen sich mit ein paar Zeilen zusätzlicher Fehlerbehandlung schließen, bevor der Flow in Produktion geht.

Zwei Wege zum Refresh-Token für Entwickler

GitHub beschreibt im Changelog zwei Wege, wie Entwickler Refresh-Token-Support in ihre App einbauen können. Der erste: den Scope offline_access in die Authentifizierungsanfrage aufnehmen, was den kurzlebigen Token-Modus für diese eine Anfrage auslöst. GitHub selbst empfiehlt genau diesen Weg zum Testen und schrittweisen Rollout, weil er pro Login-Flow steuerbar ist, ohne die App-weite Konfiguration zu verändern.

Der zweite Weg ist radikaler: die App-Registrierung fest auf kurzlebige Tokens umstellen, sodass jeder Client zwangsweise den Refresh-Flow nutzt. GitHub nennt das explizit als Mittel, um alte Clients zum Update zu zwingen und sicherzustellen, dass wirklich alle Verbindungen kurzlebige Tokens erhalten — praktisch, wenn eine SDK-Version im Feld hängen geblieben ist und niemand mehr updatet.

Für alle neu erstellten Apps sind kurzlebige Tokens ab sofort Standard. Wessen Authentifizierungs-SDK den Refresh-Token-Flow noch nicht unterstützt, kann die Funktion vorübergehend deaktivieren, während das SDK aktualisiert wird. Das ist die realistischste Einstiegshürde: Nicht jede Sprachbibliothek hat den Refresh-Flow schon nachgezogen, und wer die falsche Reihenfolge wählt, produziert sich selbst eine Ausfallwelle.

Wildcard-Redirects bergen ein reales Missbrauchsrisiko

GitHub warnt im Changelog ausdrücklich, dass Wildcard-Matching missbraucht werden kann, wenn die Zielseite keine starke Kontrolle über ihre eigenen Routen hat — etwa wenn sie Nutzerinhalte hostet. Der Mechanismus dahinter ist ein klassisches Open-Redirect-Problem: Wenn eine beliebige Subdomain oder ein beliebiger Pfad unterhalb der registrierten Redirect-URI akzeptiert wird, kann eine kompromittierte oder schwach kontrollierte Route den Autorisierungscode abfangen und damit im Namen des Nutzers auf GitHub-Ressourcen zugreifen.

Praktisch bedeutet das: Bevor ein Team Wildcard-Matching aktiv nutzt oder auch nur weiter laufen lässt, sollte es genau prüfen, wer Inhalte unter den eigenen Subdomains und Pfaden veröffentlichen kann. Bei einer statischen Marketing-Seite unter einer Subdomain ist das Risiko gering. Bei einem Plattform-Produkt, das Kunden eigene Unterseiten oder Inhalte hosten lässt, ist es real — und genau für diesen Fall lohnt sich ein Blick auf die eigene Angriffsfläche, bevor GitHub die Entscheidung stellvertretend trifft.

Wie sich Lieferketten- und Automationsrisiken auf GitHub in der Praxis auswirken können, zeigt unser Bericht über eingeschleuste Paket-Malware im Dependabot-Umfeld — ein anderer Angriffsvektor, aber dieselbe Grundregel: Je mehr implizites Vertrauen ein System vergibt, desto genauer muss jemand hinschauen, wer es tatsächlich ausnutzen kann.

Wer unsicher ist, ob eine eigene Subdomain als Ziel für Wildcard-Matching taugt, sollte sich eine einfache Frage stellen: Könnte irgendjemand außerhalb des eigenen Teams dort einen beliebigen Pfad mit eigenem Inhalt anlegen? Fällt die Antwort auch nur „vielleicht“ aus, gehört Wildcard-Matching für diese URI deaktiviert, und die betroffenen Redirect-Ziele werden stattdessen einzeln registriert.

Der Rollout-Fahrplan für Bestandsapplikationen

Alle drei Verbesserungen fließen laut GitHub vollständig in GitHub Enterprise Server 3.23 ein, was für Unternehmen mit selbst gehosteten Instanzen bedeutet: Der Umstellungsdruck kommt nicht nur über github.com, sondern folgt mit dem nächsten Enterprise-Server-Upgrade automatisch mit. Wer heute schon plant, kann sich die spätere Hektik sparen.

Ein realistischer Fahrplan für Bestandsapplikationen sieht so aus: zuerst die eigenen App-Registrierungen durchgehen und prüfen, wie viele Redirect-URIs aktuell registriert sind und ob eine einzelne URI unbeabsichtigt Wildcard-Matching aktiviert hat. Danach die Route-Kontrolle unter jeder betroffenen Subdomain bewerten, bevor Wildcard-Matching bewusst beibehalten oder deaktiviert wird. Parallel dazu den offline_access-Scope in einem Testzweig einbauen, den Refresh-Zyklus unter Last prüfen und erst danach über die härtere App-weite Umstellung auf ausschließlich kurzlebige Tokens entscheiden.

Für Teams, die mehrere OAuth-Apps parallel betreuen, lohnt sich zusätzlich eine kurze Inventarliste: Welche App hat wie viele Redirect-URIs, welches SDK wird verwendet, unterstützt es den Refresh-Flow schon, und wer im Team ist für die Migration verantwortlich? Diese zehn Minuten Aufwand pro App verhindern zuverlässiger als jede Ad-hoc-Recherche mitten in einem Incident, dass eine vergessene Integration beim harten Umschalten auf kurzlebige Tokens plötzlich ausfällt.

GitHub OAuth Refresh Tokens sind damit kein Ereignis für einen einzelnen Nachmittag, sondern ein mittelfristiges Migrationsprojekt mit klar sequenzierten Schritten. Wer die Reihenfolge einhält — zuerst Redirect-URIs und Wildcard-Verhalten auditieren, dann den Refresh-Flow testen, erst zuletzt zwangsweise umstellen — kommt ohne größere Ausfälle durch die Umstellung. Wer sie überspringt, merkt es garantiert an einem Montagmorgen, wenn plötzlich reihenweise Sessions mit einem 401 sterben.