GitHub App: Stateless Installation Tokens jetzt Standard
GitHub hat die Umstellung auf neue Installation Tokens für Apps abgeschlossen. Tokens sind nun länger, schneller zu validieren und zuverlässiger – bestehende Tokens funktionieren weiter.
Was ist neu
Seit dem 27. April 2026 führt GitHub ein neues Format für Installation Tokens aus. Diese Umstellung ist nun vollständig abgeschlossen: Alle neu erstellten Installation Tokens verwenden standardmäßig das Format ghs_APPID_JWT (stateless). Laut GitHub macht dieses Format die Token-Ausstellung und -Validierung schneller und verbessert die Zuverlässigkeit der GitHub API.
Das äußerlich sichtbarste Merkmal ist die Länge: Neue Tokens sind etwa 520 Zeichen lang, statt wie bisher 40 Zeichen. Sie beginnen weiterhin mit dem Präfix ghs_, folgen aber einer neuen internen Struktur ohne externe Zustandsspeicherung. Alle anderen Eigenschaften von Installation Tokens bleiben unverändert – Berechtigungen, Repository-Scoping, die einstündige Gültigkeitsdauer und der REST-API-Endpunkt für Installation Access Tokens funktionieren wie gewohnt.
GitHub hatte während einer Übergangszeit (ab April 2026) einen temporären HTTP-Request-Header X-GitHub-Stateless-S2S-Token bereitgestellt, mit dem Entwickler das neue Format validieren konnten, bevor es zum Standard wurde. Dieser Header wird am 30. November 2026 eingestellt. Nach diesem Datum respektiert GitHub den Header nicht mehr, und alle berechtigten Apps erhalten automatisch stateless Tokens im neuen Format.
Installation Tokens, die vor dieser Änderung ausgestellt wurden, funktionieren bis zu ihrer normalen Gültigkeitsdauer weiter. Ein sofortiger Wechsel aller bestehenden Tokens ist nicht erforderlich.
GitHub empfiehlt Entwicklern, bis zum 30. November 2026 alle Systeme zu prüfen, die Installation Tokens verarbeiten. Besondere Aufmerksamkeit gilt Validierungslogik, die eine exakte Länge von 40 Zeichen erwartet, festen Zeichenlängen in Datenbanken oder Secret-Stores, Proxies oder Middleware, die lange Authorization-Header kürzen oder ablehnen, sowie Logging- und Secret-Redaction-Regeln, die nur das alte Token-Format erkennen. Tokens sollten als undurchsichtige Zeichenketten behandelt werden, nicht als strukturierte Daten mit fester Länge.
Für wen, ab wann, zu welchen Bedingungen
Die Änderung betrifft alle Entwickler und Organisationen, die GitHub Apps entwickeln oder nutzen – insbesondere solche, die Installation Tokens für die Authentifizierung von App-Anfragen an die GitHub API verwenden. Die Umstellung ist bereits abgeschlossen, alle neu erstellten Tokens folgen bereits dem neuen Format.
Bestehende Tokens im alten Format (40 Zeichen) funktionieren unverändert bis zum Ablauf ihrer einstündigen Gültigkeitsdauer. Es gibt keinen Preis, keine Tarifpläne oder regionale Einschränkungen – die Änderung gilt für alle GitHub-Apps auf allen Konten.
Der kritische Termin für Handeln ist der 30. November 2026. Bis dahin sollte der temporäre Header X-GitHub-Stateless-S2S-Token aus dem Produktionscode entfernt werden. Nach diesem Datum wird GitHub den Header ignorieren. Entwickler, die ihre Integrations-Systeme nicht rechtzeitig anpassen – insbesondere Validierungslogik, Datenspeicher und Middleware – riskieren, dass ihre Apps nicht mehr korrekt mit den neuen Tokens umgehen können.
Einordnung für DACH
Für Teams im DACH-Raum bedeutet diese Änderung, dass alle GitHub-App-Integrationen bis Ende November 2026 überprüft werden müssen. Dies ist insbesondere für Unternehmen relevant, die benutzerdefinierte GitHub-Apps zur Automation verwenden oder ihre CI/CD-Pipelines auf GitHub Apps stützen.
Datenschutz und Speicherung sind nicht betroffen: Die Tokens sind ein internes GitHub-Format und unterliegen bereits GitHub-Bedingungen. Die DSGVO-Konformität der Token-Verwaltung ändert sich nicht. Unternehmen müssen jedoch sicherstellen, dass ihre eigenen Log-Dateien, Monitoring-Systeme und Secret-Management-Lösungen (etwa auf selbst betriebener Infrastruktur im DACH-Raum) die neuen Tokenformat korrekt verarbeiten und nicht mehr abschneiden.
Open-Source-Projekte und kleinere Entwickler-Teams sollten dies als Standard-Wartungsaufgabe betrachten. GitOps-Systeme, Webhooks und CI/CD-Tools (Jenkins, GitLab CI, GitHub Actions), die GitHub Apps nutzen, müssen überprüft werden. Die Längenänderung (40 auf 520 Zeichen) ist das Kernrisiko – viele ältere Systeme speichern Secrets in Feldern mit fester oder knapper Maximallänge.
Mehr zum Thema im Ressort Kategorie Coding mit KI.
Quellen
Häufige Fragen
Was ist der Unterschied zwischen den alten und neuen GitHub App Installation Tokens?
Die neuen stateless Tokens sind etwa 520 Zeichen lang und folgen dem Format ghs_APPID_JWT, während alte Tokens 40 Zeichen lang waren. Laut GitHub sind die neuen Tokens schneller zu validieren und zuverlässiger. Alle anderen Eigenschaften wie Berechtigungen, Repository-Scoping und die einstündige Gültigkeitsdauer bleiben gleich.
Bis wann muss ich meine Systeme auf das neue Token-Format anpassen?
Der kritische Termin ist der 30. November 2026. Bis dahin sollte der temporäre X-GitHub-Stateless-S2S-Token-Header aus dem Produktionscode entfernt werden. Nach diesem Datum wird GitHub den Header ignorieren und alle berechtigten Apps erhalten automatisch nur noch die neuen Tokens.
Funktionieren meine alten Installation Tokens nach der Umstellung noch?
Ja, Installation Tokens im alten Format funktionieren bis zum Ablauf ihrer einstündigen Gültigkeitsdauer weiterhin. Nach Ablauf erhalten Sie automatisch neue Tokens im neuen Format, daher müssen Sie keine bestehenden Tokens austauschen.