Zum Inhalt springen
Zurück zu Updates
24. April 2026
Tool Updatevon Claudius Neidig

GitHub App Installation Tokens: Neues Format ab April 2026

GitHub stellt App Installation Tokens auf ein neues, statisches JWT-Format um. Tokens wachsen von 40 auf rund 520 Zeichen, der Prefix ghs_ bleibt, aber Längen-Validierungen, Regex-Patterns und Datenbank-Spalten müssen vor dem Rollout angepasst werden.

Was sich am Token-Format ändert

GitHub kündigt im Changelog an, das Format von App Installation Tokens umzustellen. Die neuen Tokens folgen dem Schema ghs_APPID_JWT und sind mit rund 520 Zeichen deutlich länger als die bisherigen 40-Zeichen-Strings. Der Präfix ghs_ bleibt erhalten, sodass bestehende Token-Type-Detection weiter funktioniert.

Technisch sind die Tokens nun stateless: Das eingebettete JWT ist mit GitHubs internem Issuer signiert und enthält Installation, Application und Validierungs-Metadaten. Wer Tokens bisher als opaque String behandelt hat, ist auf der sicheren Seite.


Rollout-Timeline 2026

Der Rollout läuft in zwei Phasen:

  • 27. April, Mitte Mai 2026: Start mit GitHub Actions GITHUB_TOKEN sowie First-Party-Integrationen wie Dependabot, Slack und Teams.
  • Mitte Mai, Ende Juni 2026: Schrittweise Ausweitung auf alle App Installation Tokens, inklusive Brownout-Phase, in der GitHub gezielt abhängige Apps identifiziert.

Was Entwickler-Teams jetzt anpassen müssen

Drei typische Bruchstellen, die vor dem Rollout entschärft werden sollten:

  • Hardcodierte Längen-Validierungen (etwa token.length === 40) entfernen, denn die neuen Tokens passen nicht in diese Annahme.
  • Regex-Patterns wie ghs_[A-Za-z0-9]{36} aus Validatoren, Loggern und Secret-Scannern entfernen oder erweitern.
  • Datenbank-Spalten für Token-Storage auf mindestens 520 Zeichen erweitern, sonst werden Tokens beim Insert abgeschnitten.

Grundregel: Tokens als opaque Strings behandeln und keine Annahmen über interne Struktur, Länge oder Zeichenraum treffen. Wer das beherzigt, übersteht zukünftige Format-Wechsel ohne Codeänderung.


Enterprise-Einordnung

Plattform- und DevOps-Teams sollten jetzt drei Bereiche auditieren: eigene CI-Pipelines mit GitHub Actions, alle GitHub-App-Integrationen (intern wie extern) und Secret-Stores in Vaults oder Kubernetes-Secrets. Besonders riskant sind ältere Worker-Skripte oder Lambda-Funktionen, in denen Längen-Checks aus Defensiv-Reflex eingebaut wurden. Die fallen oft unter dem Radar moderner Linter.

Bei selbst entwickelten GitHub Apps lohnt sich ein gezielter Test gegen die Brownout-Phase ab Ende April: GitHub schaltet Tokens stichprobenartig auf das neue Format, um Fehlerquellen sichtbar zu machen.


Fazit

Die Umstellung ist technisch unaufwändig, solange der eigene Code Tokens korrekt als opaque behandelt. Wer noch alte Validierungs-Layer aus der 40-Zeichen-Ära hat, sollte sie diese Woche ausräumen, bevor der Rollout in Produktion ankommt. Empfehlung: Audit der eigenen GitHub-Integrationen, DB-Migrationen vorbereiten, Regex-Validatoren entfernen.

Diese Website verwendet Cookies. Notwendige Cookies sind immer aktiv. Analyse-Cookies (Ahrefs, PostHog) helfen mir anonym zu verstehen, welche Inhalte hilfreich sind.