GitHub Apps, 저장소 생성·설치 범위 권한 분리하고 만료 토큰 단계 전환 지원

ARCH-B

ARCH-B

GitHub Changelog 기반 · 2026년 10월 15일 · 5분 분량

1

한눈에 보는 핵심요약

GitHub가 저장소 생성과 앱 설치 저장소 관리에 전용 세분화 권한을 추가했다. 이미 승인된 앱의 저장소 확대와 사용자 토큰 만료 전환도 개선한다. 권한 축소, 설치 승인, 토큰 수명은 각각 확인해야 한다.

  • 저장소 생성 전용 권한으로 삭제·이전이 가능한 넓은 관리 권한을 줄일 수 있다.
  • 설치 저장소 변경에는 대상 저장소 권한과 조직의 승인·제한 정책이 적용된다.
  • offline_access로 특정 사용자 인증부터 만료 토큰과 갱신 토큰을 시험할 수 있다.
  • Enterprise Server의 offline_access는 3.23, 나머지 개선은 3.24 제공 예정이다.
GitHub Apps, 저장소 생성·설치 범위 권한 분리하고 만료 토큰 단계 전환 지원
이미지 제공: GitHub Changelog · 원출처 기사

저장소를 만드는 권한을 따로 요청한다

깃허브는 10월 13일 깃허브 앱과 세분화된 개인 액세스 토큰에 저장소 생성 전용 권한을 추가했다. repository_creation:write를 이용하면 삭제와 이전까지 허용하는 넓은 repository_administration:write 없이 저장소를 만들 수 있다. 자동으로 새 프로젝트를 준비하는 도구가 생성 작업 때문에 과도한 관리 권한을 받아야 했던 문제를 줄이는 변경이다.

조직 저장소 생성 REST API 문서도 쓰기 수준의 Administration 또는 Repository creation 중 하나를 허용 조건으로 제시한다. 다만 생성 권한을 쓴다고 설치 승인까지 생략되지는 않는다. 공지는 이 권한을 사용하는 앱의 설치에는 조직 관리자 승인이 필요하고, 생성한 앱이나 사용자는 새 저장소에 접근할 수 있다고 설명한다.

앱이 접근할 저장소를 관리하는 자동화

또 다른 권한인 installation_repositories:write는 조직의 앱 설치에 해당 저장소를 추가하거나 제거하는 데 쓰인다. 기존의 넓은 repo 범위 토큰에 의존하던 흐름에 앱과 세분화된 토큰을 사용할 수 있게 됐다. 사용자로 호출한다면 조직 소유자이거나 대상 저장소의 관리자여야 한다는 조건도 남는다.

설치 API 문서는 이 작업을 GitHub App installation repository access의 쓰기 권한으로 표시한다. 제거 API는 설치가 일부 저장소를 선택한 selected 방식이어야 하며, 조직의 모든 저장소에 설치된 경우 등에는 오류가 날 수 있다고 명시한다. 저장소 하나의 설치 연결을 바꾸는 권한을 조직의 모든 관리 기능을 허용하는 권한으로 넓혀 해석해서는 안 된다.

ARCH.B 분석

기존 승인 앱을 추가하는 권한과 조직 통제

설치 가이드는 조직 소유자가 이미 설치한 앱이라면 저장소 관리자가 자신이 관리하는 저장소를 기존 설치에 추가할 수 있다고 설명한다. 앱에 조직 수준 권한이 있어도 이미 조직 소유자가 승인했다는 전제가 적용된다. 이는 저장소 관리자에게 새 조직 권한을 승인하는 지위를 주는 변경과 다르다.

조직 소유자는 저장소 관리자의 앱 설치와 기존 설치에 저장소 추가를 제한할 수 있다. 공식 절차는 조직 설정의 Member privileges 아래에서 관련 허용 옵션을 해제하는 방식이다. 자체 설치를 제한하면서 앱 요청까지 막으면 요청 경로도 닫히므로, 팀은 권한을 줄이는 작업과 필요한 도구를 승인받는 업무 경로를 함께 설계해야 한다.

일부 사용자 인증부터 만료 토큰으로 옮긴다

사용자 액세스 토큰에는 offline_access 지원이 추가됐다. 앱 전체에서 토큰 만료를 꺼 둔 경우에도 특정 사용자 인증에 이 값을 요청하면 만료되는 액세스 토큰과 갱신 토큰을 받을 수 있다. 모든 사용자를 한 번에 전환하지 않고 새 흐름을 시험할 수 있는 수단이다. 이번 요청이 이후 모든 인증의 기본값을 영구 변경하는 것은 아니다.

공식 갱신 가이드는 scope 매개변수가 깃허브 앱에 새 권한을 부여하지 않는다고 명시한다. 지원되는 offline_access는 토큰 만료를 강제하는 값이며, 앱의 권한은 앱 등록에서 정한 권한과 사용자의 권한에 의해 제한된다. OAuth 앱의 권한 범위 추가와 같은 방식으로 해석하면 안 된다.

ARCH.B 분석

갱신 토큰을 받는 것에서 운영 전환까지

만료되는 사용자 액세스 토큰은 8시간, 갱신 토큰은 6개월 뒤 만료된다. 갱신 토큰을 사용하면 새 액세스·갱신 토큰 쌍이 나오고 이전 갱신 토큰과 액세스 토큰은 사용할 수 없게 된다. 클라이언트는 새 값을 안전하게 보관하고, 갱신 토큰까지 만료됐을 때 다시 사용자 인증을 진행하는 경로를 준비해야 한다.

앱 설정에서 만료를 다시 켜더라도 이미 발급된 기존 사용자 토큰에 만료 시점이 소급 적용되지는 않는다. 따라서 전환 계획에는 새 로그인 시험뿐 아니라 기존 토큰의 재인증이나 폐기 처리가 포함돼야 한다. 만료 옵션 하나를 켰다는 사실만으로 이전 자격 증명까지 모두 단명 토큰이 됐다고 보고할 수 없다.

ARCH.B 분석

서버 버전과 변경 종류별 도입 순서

깃허브닷컴에 공개된 이번 개선 가운데 offline_access는 Enterprise Server 3.23에 포함되고, 그 밖의 개선은 3.24에 제공될 예정이다. 자체 서버 운영자는 동일 공지에 있는 기능이라도 적용 버전이 다르다는 점을 반영해야 한다. 자격 증명을 별도 Credentials 탭에서 관리하는 화면 변경도 발표됐지만, 향후 워크로드 연합 기능을 위한 공간이라는 설명이지 그 기능 자체의 출시 선언은 아니다.

팀의 전환 순서는 생성 자동화의 권한 축소, 앱별 저장소 접근 목록 점검, 사용자 토큰 갱신 시험으로 나눌 수 있다. 각각 작업 권한, 자원 범위, 자격 증명 수명을 다루므로 한 항목의 완료가 다른 항목의 완료를 대신하지 않는다.

출처

GitHub Changelog의 원출처와 본문에 표시한 참고자료를 바탕으로 한국어로 재구성했습니다. ‘ARCH.B 분석’은 자료를 읽고 덧붙인 편집 해석입니다.

GitHub App improvements for least privilege and management (새 창)

Share

Related

함께 읽기 좋은 글