Jalur SSH tuntas di chapter sebelumnya; kini giliran jalur yang kelihatannya paling sederhana: HTTPS. Push pertama ke https://github.com/... akan memunculkan prompt nama pengguna dan kata sandi — dan di situlah kejutan klasik menanti: kata sandi akun yang benar justru ditolak. Sejak 13 Agustus 2021, GitHub berhenti menerima kata sandi akun untuk operasi Git lewat HTTPS, dan platform lain mengambil arah serupa. Kebijakan itu bukan kerumitan baru, melainkan perbaikan keamanan: penggantinya bernama personal access token — kredensial yang bisa dibatasi cakupannya, diberi masa berlaku, dan dicabut kapan saja tanpa menyentuh akun. Chapter ini membahas kenapa token menggantikan kata sandi, bagaimana memakainya, dan bagaimana merawatnya.
Kenapa Kata Sandi Akun Ditolak #
Kata sandi akun dirancang untuk manusia yang masuk log lewat peramban — bukan untuk skrip dan alat baris perintah. Sebagai kredensial Git, kata sandi punya tiga cacat struktural: ia membuka seluruh akun (membaca kode, mengubah profil, menghapus repository, semuanya), ia tidak berakhir (berlaku selamanya sampai diganti), dan ia satu-satunya (dicabut berarti mengunci semua perangkat sekaligus). Satu kata sandi yang bocor lewat berkas log atau laptop yang hilang memberikan penyerang kunci kerajaan penuh.
Token membalik ketiganya. Personal access token (PAT) adalah deretan karakter buatan sendiri yang berperan sebagai kata sandi khusus Git dan API: cakupannya bisa dibatasi (misalnya hanya menulis isi repository), masa berlakunya bisa dipendekkan, dan ia bisa dicabut individual tanpa mengganggu kredensial lain. Bitbucket Cloud menempuh jalan yang sama — kata sandi akun untuk operasi Git dihentikan dan digantikan app password, yang kini dikonsolidasikan Atlassian ke dalam API tokens.
Dua Jenis Token di GitHub #
GitHub menyediakan dua jenis PAT dengan falsafah cakupan yang berbeda:
| Aspek | Classic | Fine-grained |
|---|---|---|
| Cakupan repository | seluruh repository yang dapat diakses akun | dipilih satu per satu saat pembuatan |
| Model izin | scope kasar — repo membuka isi semua repository | izin granular per kategori, mis. isi repo baca/tulis saja |
| Kedaluwarsa | dipilih saat pembuatan, bisa tanpa batas | dipilih saat pembuatan; kebijakan organisasi dapat memaksakan batas |
| Posisinya | format lama yang tetap didukung | arah pengembangan GitHub saat ini |
Aturan praktisnya sederhana: untuk kebutuhan pribadi sehari-hari, fine-grained token dengan izin terbatas pada repository tertentu adalah pilihan paling aman; classic tetap berguna bila alat pihak ketiga belum mendukung format barunya. Panduan pembuatan kedua jenisnya terdokumentasi di dokumentasi GitHub tentang personal access token .
Cara Memakainya di Prompt Git #
Alurnya tidak butuh perintah baru — Git tetap meminta kredensial seperti biasa, dan token tinggal ditempelkan sebagai kata sandi. Saat git push pertama ke remote HTTPS, terminal menampilkan prompt dengan bentuk kurang-lebih seperti ini:
Username for 'https://github.com': budi
Password for 'https://[email protected]': Bagian Username diisi nama pengguna akun, dan bagian Password diisi token — bukan kata sandi akun. Token tidak ditampilkan saat ditempelkan, sama perilakunya dengan input rahasia lainnya. Penting dicatat bentuk prompt di atas adalah ilustrasi perilaku Git, bukan keluaran sandbox: sandbox memang tidak menjalankannya karena membutuhkan token asli, dan kita tidak akan pernah menulis token sungguhan di materi ini — cukup yakin token tiruan seperti YOUR_GITHUB_TOKEN akan diterima platform tepat seperti token asli.
Setelah prompt terisi, Git mengingat identitasnya selama operasi berjalan. Pada push berikutnya prompt serupa muncul lagi — kecuali credential helper mengambil alih penyimpanannya, pokok bahasan singkat di bawah.
Penyimpanan: Credential Helper #
Menyalin-tempel token tiap push terasa cepat membosankan. Git menyelesaikannya lewat credential helper: komponen yang menyimpan kredensial HTTPS dan menyodorkannya otomatis saat diminta. Git menyediakan beberapa backend — penyimpanan sementara di memori (cache), berkas biasa (store), dan brankas sistem operasi seperti Keychain di macOS atau Windows Credential Manager. Pilihan backend dan kompromi keamanannya dibedah tuntas di Credential Helper
.
Rotasi dan Pencabutan #
Token bukan benda sekali buat selamanya. Halaman pengaturan token di platform menyediakan tiga tombol yang menjadi denyut perawatannya: regenerate (mengganti nilai token tanpa menghapus izinnya), revoke (mematikan token seketika), dan pengaturan kedaluwarsa yang mengakhirinya otomatis. Kebijakan sehatnya: satu token per peruntukan — satu untuk laptop, satu untuk skrip CI, satu untuk alat pihak ketiga — supaya saat salah satu perangkat hilang, hanya token miliknya yang dicabut. Prinsip cakupan minimalnya dibahas lebih jauh di Mengelola Token dan Least Privilege .
Tiga Platform, Satu Konsep #
| Platform | Nama fiturnya | Ciri khasnya |
|---|---|---|
| GitHub | personal access token | dua jenis: classic dan fine-grained |
| GitLab | personal access token | scope per aktivitas, mis. read_repository atau write_repository |
| Bitbucket | app password / API token | izin bernama per kategori; kini dikonsolidasikan ke API tokens |
Konsepnya seragam — kredensial terbatas yang menggantikan kata sandi — hanya kosakata dan halaman pengaturannya yang berbeda. Rincian scope dan pembuatannya terdokumentasi di dokumentasi GitLab tentang personal access token dan dokumentasi Atlassian tentang API tokens .
Dua jalur autentikasi kini lengkap: kunci SSH untuk jalur yang sunyi, token terbatas untuk jalur yang terukur. Dengan akses di tangan, pembahasan berikutnya berpindah dari bagaimana masuk ke bagaimana berkontribusi — alur paling khas dunia open source: fork, branch, pull request. Alur itu kita jalankan utuh di chapter berikutnya.