Installations-Tokens für GitHub Apps wachsen von 40 auf rund 520 Zeichen

Victoria Shinder03 October 2026, 12:492 Min. Lesezeit

GitHub hat die Umstellung der Installations-Tokens für GitHub Apps auf ein neues, zustandsloses Format abgeschlossen, wie das Unternehmen im Changelog mitteilt. Der schrittweise Rollout begann am 27. April 2026; ab jetzt erhält jedes neu ausgestellte Installations-Token standardmäßig die Form ghs_APPID_JWT. Laut GitHub werden Tokens dadurch schneller ausgestellt und geprüft, und die API wird zuverlässiger.

Sichtbar ist vor allem die Länge. Die Tokens beginnen weiterhin mit ghs_, sind aber nun rund 520 statt 40 Zeichen lang. Alles andere, worauf sich Aufrufer verlassen, bleibt gleich: Berechtigungen, Beschränkung auf Repositories, die Gültigkeit von einer Stunde und der REST-Endpunkt, der die Tokens ausgibt. Vor der Umstellung erzeugte Tokens funktionieren bis zu ihrem Ablauf.

Es gibt außerdem eine Frist. Während des Rollouts konnten Apps das neue Format über den temporären Header X-GitHub-Stateless-S2S-Token gezielt anfordern, um beide Formate parallel zu testen. Dieser Header wird am 30. November 2026 abgekündigt. Danach ignoriert GitHub ihn, und alle berechtigten Apps erhalten immer zustandslose Tokens – der Header sollte also vorher aus dem Produktivcode verschwinden.

Das Changelog nennt die typischen Bruchstellen. Alle sind Orte, an denen Code ein Token als etwas mit bekannter Form behandelt hat statt als undurchsichtige Zeichenkette:

• Prüfungen, die genau 40 Zeichen erwarten, oder reguläre Ausdrücke für das alte Format;
• Datenbankspalten, Secret-Speicher oder Umgebungsvariablen mit kleiner fester Maximallänge;
• Proxys, Gateways oder Middleware, die lange Authorization-Header abschneiden oder ablehnen;
• Regeln für Logging und Schwärzung, die nur das alte Token-Muster erkennen.

Warum das wichtig ist

Der letzte Punkt ist der leise. Ein Token, das an einer 40-Zeichen-Spalte scheitert, fällt sofort auf; ein Token, das nicht mehr zum Schwärzungsmuster passt, landet vollständig im Log, und niemand merkt es, bis jemand die Logs liest. Wer CI-Systeme, Bots oder interne Werkzeuge betreibt, die Installations-Tokens ausstellen, sollte neben Speichergrenzen auch Secret-Scanning und Log-Maskierung prüfen – und den Code nach dem temporären Header durchsuchen, solange noch zwei Monate Zeit sind.