GitHub CLI 2.103.0 cho phép dùng OAuth token hết hạn và tự làm mới

Cơ chế thử nghiệm mới rút ngắn tuổi thọ access token, đồng thời duy trì đăng nhập bằng refresh token luân chuyển. Script lưu token một lần cần được rà soát.

Tháng 10 22, 2026

GitHub ngày 21/10/2026 đưa cơ chế OAuth token có thời hạn và tự làm mới vào bản thử nghiệm công khai của GitHub CLI 2.103.0. Người dùng có thể giữ phiên đăng nhập mà không phải dựa vào một access token tồn tại vô thời hạn. Thay đổi này cần được xem xét cùng những script đang lấy token từ công cụ rồi lưu lại để dùng về sau.

Đây là lựa chọn chủ động bật, theo thông báo phát hành. Người không bật chế độ mới tiếp tục sử dụng cơ chế hiện tại. Vì vậy, nâng cấp ứng dụng và chuyển thông tin xác thực sang chế độ mới là hai việc khác nhau.

Một token ngắn hạn được duy trì bằng token làm mới

Access token là thông tin được gửi khi công cụ cần truy cập tài nguyên được cấp quyền. Khi có thời hạn, nó chỉ sử dụng được trong khoảng thời gian xác định. Refresh token phục vụ việc lấy một access token mới; người dùng không phải thực hiện lại toàn bộ bước đăng nhập mỗi khi access token cũ hết hạn.

Tài liệu OAuth của GitHub mô tả access token hết hạn sau tám giờ và refresh token hết hạn sau sáu tháng không sử dụng. Khi làm mới, hệ thống cấp access token và refresh token mới. Đây là thông tin về cơ chế OAuth, không phải cam kết rằng bất kỳ chuỗi ký tự nào được đưa vào CLI cũng sẽ được tự gia hạn.

Về bảo mật, cửa sổ sử dụng của một access token bị lộ được thu hẹp. Nhưng refresh token vẫn cần được bảo vệ, vì nó có vai trò duy trì khả năng truy cập. Không nên diễn giải thay đổi này thành việc token bị đánh cắp đã trở nên vô hại hoặc người dùng có thể bỏ qua cách lưu bí mật trên máy.

Bật chế độ mới không khó, nhưng cần kiểm tra kết quả

Ghi chú phiên bản 2.103.0 hướng dẫn đăng nhập bằng gh auth login --expiring. Có thể đặt lựa chọn cho những lần đăng nhập tiếp theo bằng gh config set expiring_credentials enabled. Lệnh gh auth status cho biết trạng thái thông tin xác thực và thời điểm hết hạn.

CLI có phương án quay về token không hết hạn nếu máy chủ chưa hỗ trợ. Vì vậy, chạy thành công lệnh đăng nhập chưa đủ để kết luận đã nhận token ngắn hạn. Kiểm tra trạng thái sau thao tác giúp xác định cơ chế thực tế đang dùng, thay vì suy từ cấu hình mà người dùng yêu cầu.

Git qua HTTPS cần công cụ biết cách làm mới thông tin xác thực

CLI và Git là hai thành phần cần phối hợp. Hướng dẫn xác thực GitHub CLI khuyến nghị dùng gh auth setup-git để CLI làm credential helper cho Git qua HTTPS. Khi đó, công cụ cung cấp thông tin xác thực phù hợp cho thao tác Git.

GitHub cũng khuyến nghị Git 2.46 trở lên để credential helper có thể đánh dấu thời hạn và tránh lưu token quá lâu. Điểm cần rà soát trong môi trường phát triển là đường đi của thông tin xác thực: thành phần nào đang cấp token, thành phần nào lưu và thành phần nào chịu trách nhiệm thay thế khi nó hết hạn.

Một cấu hình hoạt động trong terminal tương tác chưa chứng minh mọi tiến trình tự động trên cùng máy sẽ dùng chung đường đi đó. Tài khoản chạy dịch vụ, cấu hình theo người dùng và cách truyền biến môi trường có thể tạo ra những luồng khác nhau. Đây là câu hỏi vận hành cần tự kiểm tra tại môi trường triển khai.

Script giữ bản sao token là điểm dễ phát sinh lỗi

Trước đây, một script có thể lấy kết quả từ gh auth token rồi tái sử dụng qua nhiều lần chạy. Với token ngắn hạn, bản sao đó có thể hết hiệu lực trong khi phiên đăng nhập của CLI vẫn hoạt động. Chức năng làm mới của CLI không đồng nghĩa mọi nơi từng sao chép token đều được cập nhật.

Ghi chú phát hành yêu cầu lấy token mới mỗi khi cần thay vì giữ bản cũ, đồng thời nêu rằng token được cấp qua GH_TOKEN hoặc GITHUB_TOKEN không được CLI tự làm mới. Sự phân biệt này đặc biệt quan trọng khi rà soát script và extension, nơi nguồn token có thể khác một phiên đăng nhập thông thường.

Thay đổi nhỏ ở đăng nhập, thay đổi lớn ở cách kiểm tra luồng chạy

Một thử nghiệm phù hợp nên bao gồm cả lần chạy sau khi access token ban đầu hết hạn, chứ không chỉ thao tác đăng nhập đầu tiên. Nhóm phát triển cần biết hệ thống có tự lấy thông tin hợp lệ, thông báo lỗi có đủ rõ và có đoạn nào đang âm thầm giữ bản sao cũ hay không.

Bài viết chưa thử nghiệm phiên bản này trên môi trường sản xuất. Giá trị thực tế của cơ chế mới phụ thuộc việc các công cụ liên quan cùng xử lý đúng vòng đời token. Bước cần làm trước khi áp dụng rộng là xác định nơi cấp, nơi lưu và nơi tiêu thụ thông tin xác thực trong từng luồng công việc.

Ảnh: logo GitHub nguyên trạng từ GitHub Brand Toolkit, dùng nhận diện hãng theo mục Blog posts and news. Đây là ảnh minh họa thương hiệu, không phải giao diện tính năng.