GitHub menyelesaikan rollout format baru untuk installation access token milik GitHub App pada 2 Oktober 2026. Token yang baru dibuat kini secara default memakai format stateless ghs_APPID_JWT, bukan format lama yang panjangnya sekitar 40 karakter. Perubahan ini tidak mengubah izin, pembatasan repository, masa berlaku satu jam, atau endpoint REST yang dipakai untuk menerbitkan token. Yang berubah adalah bentuk tokennya—dan detail kecil itu cukup untuk mematahkan integrasi yang terlalu bergantung pada format lama.

GitHub mengatakan format stateless membuat penerbitan dan validasi token lebih cepat serta meningkatkan keandalan API. Rollout bertahapnya dimulai pada 27 April 2026. Selama masa transisi, token lama masih dapat dipakai sampai kedaluwarsa. Setelah rollout selesai, aplikasi yang meminta token baru akan menerima string yang jauh lebih panjang, meski tetap diawali ghs_.

Masalahnya bukan izin, melainkan asumsi

Secara fungsional, token baru masih membawa peran yang sama. Installation token dipakai aplikasi untuk bertindak atas nama instalasi GitHub App, dengan akses yang dibatasi oleh izin aplikasi dan repository yang dipilih. Token tetap berlaku selama satu jam. Pengembang juga masih dapat memakai endpoint POST /app/installations/{installation_id}/access_tokens untuk mendapatkannya.

Risikonya muncul ketika sebuah sistem memperlakukan token sebagai sesuatu yang lebih spesifik daripada sekadar rahasia acak. GitHub meminta pengelola integrasi memeriksa validasi yang mengharuskan token tepat 40 karakter, pola regex yang hanya mengenali bentuk lama, serta kolom database atau secret store yang memiliki batas panjang terlalu kecil. Middleware, proxy, dan gateway juga perlu diperiksa karena header Authorization membawa token baru yang lebih panjang.

Aturan logging dan redaksi rahasia menjadi titik lain yang mudah terlewat. Sebuah pipeline mungkin sudah menyembunyikan token lama berdasarkan awalan dan panjang tertentu, tetapi gagal mengenali format baru. Jika itu terjadi, token dapat muncul di log CI, error tracker, trace request, atau sistem observability. Token tetap hanya berlaku satu jam, tetapi kebocoran kredensial sementara tetap cukup untuk memberi akses yang seharusnya tidak tersedia.

Header transisi punya tanggal kedaluwarsa

Untuk membantu pengujian, GitHub sebelumnya menyediakan header request sementara bernama X-GitHub-Stateless-S2S-Token. Header itu dapat dipakai untuk memvalidasi aplikasi dan workflow dengan format stateless secara on demand. Namun, mekanisme transisi tersebut tidak akan bertahan selamanya. GitHub menyatakan header itu akan didepresiasi pada 30 November 2026 dan setelah tanggal tersebut tidak lagi dihormati.

Artinya, header tersebut bukan solusi permanen dan bukan alasan untuk menunda pemeriksaan. Integrasi perlu diuji dengan kedua format token selama masa transisi, lalu header sementara harus dihapus dari kode produksi sebelum tenggat. Sistem yang hanya dites dengan token lama berisiko terlihat baik sampai GitHub menerbitkan token baru secara default.

Cara memeriksa integrasi

Langkah pertama adalah mencari pemeriksaan panjang atau pola token di seluruh repository. Fokusnya bukan hanya pada kode yang memanggil GitHub, tetapi juga pada library internal, webhook handler, worker, file konfigurasi, dan skrip deployment. Cari angka 40 yang dipakai untuk memvalidasi token, regex yang mengunci bentuk lama, serta tipe database seperti varchar(40) atau batas secret yang dibuat berdasarkan asumsi lama.

Langkah berikutnya adalah mengikuti perjalanan token dari penerbitan sampai pemakaian. Pastikan aplikasi tidak memotong string, menormalisasi karakter, memasukkannya ke URL, atau memaksa token melewati batas header tertentu. Token seharusnya diperlakukan sebagai opaque string: diterima, disimpan hanya selama diperlukan, dikirim melalui header yang aman, lalu dibuang ketika tidak lagi dibutuhkan. Tidak ada manfaat operasional untuk membaca isi token atau menebak informasi dari panjangnya.

Pengujian juga perlu memasukkan lapisan yang sering berada di luar repository utama. Periksa reverse proxy, API gateway, service mesh, secret manager, sistem audit, serta aturan penyensoran log. Pengembang biasanya menguji request langsung dari aplikasi ke GitHub, sementara kegagalan justru terjadi ketika request melewati komponen perantara yang memiliki batas ukuran atau parser sendiri.

GitHub tidak mengumumkan perubahan pada scope permission atau cara memilih repository. Karena itu, organisasi tidak perlu merancang ulang model otorisasi hanya karena format token berubah. Fokus yang lebih tepat adalah kompatibilitas dan pengelolaan rahasia. Jika integrasi menggunakan Octokit SDK, sebagian pekerjaan penerbitan dan regenerasi token dapat ditangani SDK. Meski begitu, lapisan di sekitar SDK tetap perlu diuji karena token pada akhirnya dapat melewati log, storage, proxy, atau sistem monitoring milik organisasi.

Perubahan kecil yang menguji kedewasaan sistem

Perubahan ini mengingatkan bahwa kredensial sebaiknya tidak pernah diperlakukan seperti identifier dengan format tetap. Panjang token bisa berubah, awalan bisa bertambah, dan metode validasi dapat diperbarui tanpa mengubah tujuan aksesnya. Kode yang hanya bertanya “apakah string ini token lama?” akan lebih rapuh daripada kode yang hanya memastikan token tersedia, tidak kosong, dikirim ke tujuan yang benar, dan tidak bocor ke log.

Bagi pengelola GitHub App, pekerjaan paling mendesak bukan mengganti endpoint. Buat token baru dengan format yang sudah berlaku, jalankan pengujian melalui seluruh jalur aplikasi, periksa log dan penyimpanan rahasia, lalu hapus header transisi sebelum 30 November 2026. Jika semua komponen memperlakukan installation token sebagai opaque string dan tidak mengunci panjangnya, perubahan ini seharusnya cukup menjadi pekerjaan kompatibilitas—bukan insiden produksi.

Sumber - GitHub Changelog, “Stateless GitHub App installation tokens rolled out” (2 Oktober 2026): https://github.blog/changelog/2026-10-02-stateless-github-app-installation-tokens-rolled-out/

Sumber tambahan: - GitHub Docs, “Generating an installation access token for a GitHub App”: https://docs.github.com/en/apps/creating-github-apps/authenticating-with-a-github-app/generating-an-installation-access-token-for-a-github-app - GitHub Docs, “Authenticating as a GitHub App installation”: https://docs.github.com/en/apps/creating-github-apps/authenticating-with-a-github-app/authenticating-as-a-github-app-installation

Konteks: - GitHub REST API, “Create an installation access token”: https://docs.github.com/en/rest/apps/installations#create-an-installation-access-token