GitHub Apps เพิ่มสิทธิ์ละเอียด สร้างรีโปได้โดยไม่ต้องถือสิทธิ์ผู้ดูแลทั้งหมด

GitHub ประกาศชุดปรับปรุง GitHub Apps เมื่อวันที่ 13 ตุลาคม 2026 โดยเพิ่มสิทธิ์ละเอียดสำหรับสร้างรีโปและจัดการว่าการติดตั้งแอปเข้าถึงรีโปใด ลดความจำเป็นที่ระบบอัตโนมัติจะถือ classic personal access token หรือสิทธิ์ผู้ดูแลรีโปที่กว้างเกินงานจริง ข่าวนี้ควรอ่านในมุมของการออกแบบสิทธิ์: ถ้างานต้องสร้างรีโปอย่างเดียว ก็ไม่ควรต้องมีสิทธิ์ลบหรือโอนรีโปด้วย

สิทธิ์ใหม่สองตัวแก้อะไร

สิทธิ์ repository_creation:write อนุญาตให้ผู้เรียกสร้างรีโปในบัญชีที่ได้รับสิทธิ์ โดยไม่ต้องขอ repository_administration:write แบบเดิม ซึ่งมีความสามารถด้านการบริหารอื่นรวมถึงการลบและโอนรีโปด้วย ตามประกาศของ GitHub แอปที่ใช้สิทธิ์สร้างรีโปยังต้องให้ผู้ดูแลองค์กรติดตั้งก่อน และเมื่อสร้างรีโปแล้วแอปหรือผู้ใช้ที่สร้างจะได้รับการเข้าถึงรีโปนั้น เงื่อนไขนี้สำคัญเพราะสิทธิ์ที่แคบลงไม่ได้หมายความว่าใครก็สามารถสร้างรีโปในองค์กรได้โดยไม่ผ่านการอนุมัติ

อีกสิทธิ์คือ installation_repositories:write สำหรับเพิ่มหรือถอดรีโปออกจาก installation ของ GitHub App ภายในองค์กร API ที่เคยต้องใช้ scope repo แบบกว้างรองรับ GitHub Apps และ fine-grained PAT แล้ว หากผู้เรียกเป็นผู้ใช้ ยังต้องเป็นเจ้าขององค์กรหรือผู้ดูแลรีโปนั้นด้วย ความหมายเชิงปฏิบัติคือทีม platform สามารถทำระบบ self-service สำหรับเปิดแอปที่องค์กรอนุมัติไว้ให้รีโปหนึ่ง โดยไม่ต้องเก็บ PAT ของผู้ดูแลองค์กรที่เข้าถึงรีโปจำนวนมาก

ผู้ดูแลรีโปเพิ่มแอปที่อนุมัติแล้วได้ง่ายขึ้น

เดิม GitHub จำกัดการติดตั้งแอปที่ขอสิทธิ์ระดับองค์กร แม้แอปนั้นมีการติดตั้งอยู่ในองค์กรแล้ว การเปลี่ยนครั้งนี้ให้ผู้ดูแลรีโปเพิ่มรีโปของตนเข้า installation เดิมได้ หากเจ้าขององค์กรอนุมัติแอปและสิทธิ์ระดับองค์กรไว้ก่อน GitHub อธิบายว่าไม่ได้เพิ่มสิทธิ์ระดับองค์กรใหม่ให้แอป แต่ผู้ดูแลยังควรตรวจสิทธิ์ของแอปทั้งหมดก่อนเพิ่มรีโป เพราะการเปิดทางเข้าถึงโค้ดและ metadata ของรีโปใหม่เป็นผลจริงที่ต้องยอมรับ

องค์กรที่ต้องการรวมการอนุมัติไว้กับเจ้าขององค์กรยังมีตัวเลือกจำกัดการติดตั้ง GitHub App ให้เจ้าขององค์กรจัดการเท่านั้น ดังนั้นการเปลี่ยนค่าเริ่มต้นให้คล่องขึ้นไม่ควรถูกตีความว่าทุกองค์กรต้องเปิด self-service เท่ากัน ควรกำหนดว่าแอปประเภทใดอนุญาต เช่น CI และ issue automation ที่ผ่านการตรวจแล้ว ส่วนแอปที่อ่าน source code หรือเขียน release อาจต้อง review แยก

Token หมุนเวียนและ offline_access

GitHub Apps รองรับ scope offline_access เพื่อช่วยย้ายแอปที่เคยใช้ user access token ไม่หมดอายุไปใช้ token อายุสั้นและ refresh token การขอ scope นี้ทำให้คำขอที่เกี่ยวข้องได้รับ refresh token เพิ่ม แต่ไม่ได้เปลี่ยนสิทธิ์ GitHub App ที่กำหนดไว้ในการลงทะเบียน และไม่ได้ทำให้ทุก session หลังจากนั้นเปลี่ยนพร้อมกัน ทีมพัฒนาจึงสามารถทยอยเปิดในกลุ่มทดสอบ ตรวจการ refresh และการจัดเก็บ token ก่อน rollout เต็มระบบได้

การใช้ refresh token ไม่ได้ลดความสำคัญของการป้องกัน secret ต้องเก็บอย่างปลอดภัย มีการหมุนเวียนและเพิกถอนเมื่อถูกเปิดเผย และไม่เขียนลง log หรือส่งต่อไปยัง frontend การออกแบบนี้ช่วยลดอายุของ access token ที่หลุด แต่ refresh token เองยังเป็น credential ที่ต้องดูแลเข้มงวด

งานดูแลแอปและเวอร์ชัน Enterprise Server

ประกาศระบุว่าแอปสามารถเรียกข้อมูลของแอป private และ internal อื่นได้ภายใต้ขอบเขตเจ้าของที่กำหนด เช่น แอปในองค์กรเดียวกัน หรือ internal app ภายใน enterprise เดียวกัน ฟีเจอร์นี้ช่วยทำ inventory และ audit ได้โดยไม่ต้องพึ่งบัญชีบุคคล ขณะเดียวกันหน้า Credentials ใหม่รวม client secrets และ key pairs เพื่อให้ผู้ดูแลพบและจัดการได้ง่ายขึ้น GitHub ระบุว่า offline_access มีใน GHES 3.23 ส่วนการปรับปรุงอื่นในประกาศจะอยู่ใน GHES 3.24 ผู้ใช้ GitHub Enterprise Server จึงต้องตรวจเวอร์ชันก่อนวางแผนใช้งาน

ทีมที่มี automation ถือ classic PAT ควรเริ่มจากทำรายการว่าแต่ละ token ใช้ API ใดจริง แล้วจับคู่กับสิทธิ์ใหม่หรือสิทธิ์ GitHub App ที่แคบที่สุด ทดสอบในองค์กรทดลอง ตรวจ audit log เมื่อสร้างรีโปหรือเพิ่ม installation และกำหนดเจ้าของแอปที่รับผิดชอบ credential การย้ายแบบนี้ให้ผลด้านความปลอดภัยมากกว่าการเปลี่ยนชนิด token แต่คงสิทธิ์กว้างเหมือนเดิม

ข่าวนี้เปิดทางให้จัดสิทธิ์ GitHub Apps ละเอียดขึ้นและลดการพึ่ง PAT แบบกว้าง แต่ต้องใช้ร่วมกับขั้นอนุมัติขององค์กร การตรวจแอปที่ติดตั้ง และการดูแล credential อย่างต่อเนื่อง

แหล่งข่าวและวันที่ประกาศ: GitHub Changelog, 13 ตุลาคม 2026