# OAuth 앱에 대한 범위
범위를 사용하면 필요한 액세스 유형을 정확히 지정할 수 있습니다. 범위는 OAuth 토큰에 대한 액세스를 _제한_합니다. 사용자가 이미 가지고 있는 것 이상의 추가 권한은 부여하지 않습니다.
> \[!NOTE]
> GitHub App 대신 OAuth app을 빌드하는 것을 고려하세요. GitHub Apps 범위 대신 세분화된 사용 권한을 사용하면 앱이 수행할 수 있는 작업을 더 잘 제어할 수 있습니다. 자세한 내용은 [GitHub 앱과 OAuth 앱 간의 차이점](/ko/enterprise-server@3.22/apps/oauth-apps/building-oauth-apps/differences-between-github-apps-and-oauth-apps) 및 [GitHub 앱 만들기 정보](/ko/enterprise-server@3.22/apps/creating-github-apps/about-creating-github-apps/about-creating-github-apps)을(를) 참조하세요.
GitHub에서 OAuth app를 설정할 때 권한 부여 양식에 요청된 권한 범위가 사용자에게 표시됩니다.
> \[!NOTE]
> GitHub 앱을 빌드하는 경우 권한 부여 요청에 범위를 제공할 필요가 없습니다. 자세한 내용은 [사용자를 대신하여 GitHub 앱으로 인증](/ko/enterprise-server@3.22/apps/creating-github-apps/authenticating-with-a-github-app/authenticating-with-a-github-app-on-behalf-of-a-user)을(를) 참조하세요.
OAuth app CLI 도구와 같은 브라우저에 액세스할 수 없는 경우 사용자가 앱에 인증할 범위를 지정할 필요가 없습니다. 자세한 내용은 [OAuth 앱 권한 부여](/ko/enterprise-server@3.22/apps/oauth-apps/building-oauth-apps/authorizing-oauth-apps#device-flow)을(를) 참조하세요.
헤더를 확인하여 사용 중인 OAuth 범위와 API 작업이 무엇을 허용하는지 확인합니다.
```shell
$ curl -H "Authorization: Bearer OAUTH-TOKEN" http(s)://HOSTNAME/api/v3/users/codertocat -I
HTTP/2 200
X-OAuth-Scopes: repo, user
X-Accepted-OAuth-Scopes: user
```
* `X-OAuth-Scopes`는 토큰에 권한이 부여된 범위를 나열합니다.
* `X-Accepted-OAuth-Scopes`는 작업이 검사하는 범위를 나열합니다.
## 사용 가능한 범위
| 이름 | 설명 |
| ---------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **`(no scope)`** | 공개 정보에 대한 읽기 전용 액세스 권한 부여(사용자 프로필 정보, 리포지토리 정보 및 gists 포함) |
| **`site_admin`** | 사이트 관리자에게 [관리 API 엔드포인트에GitHub Enterprise Server](/ko/enterprise-server@3.22/rest/enterprise-admin) 대한 액세스 권한을 부여합니다. |
| **`repo`** | 코드에 대한 읽기 및 쓰기 액세스, 커밋 상태, 리포지토리 초대, 협력자, 배포 상태 및 리포지토리 웹후크를 포함하여 공용, 내부 및 프라이빗 리포지토리에 대한 모든 권한을 부여합니다. |
| **참고**: 리포지토리 관련 리소스 외에도 `repo` 범위는 프로젝트, 초대, 팀 멤버 자격 및 웹후크를 포함하여 조직 소유 리소스를 관리할 수 있는 액세스 권한을 부여합니다. 이 범위는 사용자가 소유한 프로젝트를 관리하는 기능도 부여합니다. | |
| `repo:status` | |
| 공개, 비공개 및 내부 리포지토리의 커밋 상태에 대한 읽기/쓰기 권한을 부여합니다. 이 범위는 코드에 대한 액세스 권한을 부여하지 *않고* 다른 사용자 또는 서비스에 프라이빗 리포지토리 커밋 상태에 대한 액세스 권한을 부여하는 데만 필요합니다. | |
| `repo_deployment` | 퍼블릭 및 프라이빗 리포지토리의 [배포 상태](/ko/enterprise-server@3.22/rest/repos#deployments)에 대한 액세스 권한을 부여합니다. 이 범위는 코드에 대한 액세스 권한을 부여하지 *않고* 다른 사용자 또는 서비스에 배포 상태에 대한 액세스 권한을 부여하는 데만 필요합니다. |
| `public_repo` | 퍼블릭 리포지토리에 대한 액세스 제한 여기에는 퍼블릭 리포지토리 및 조직의 코드, 커밋 상태, 리포지토리 프로젝트, 협력자 및 배포 상태에 대한 읽기/쓰기 액세스가 포함됩니다. 공개 리포지토리에 별표를 표시할 때도 필요합니다. |
| `repo:invite` | 리포지토리에서 협업하는 초대의 수락/거절 기능을 부여합니다. 이 범위는 코드에 대한 액세스 권한을 부여하지 *않고* 다른 사용자 또는 서비스에 초대에 대한 액세스 권한을 부여하는 데만 필요합니다. |
| `security_events` | 권한:
|
| \[ | |
| code scanningAPI]\(/rest/code-scanning)의 보안 이벤트에 대한 읽기 및 쓰기 권한
이 범위는 코드에 대한 액세스 권한을 부여하지 *않고* 다른 사용자 또는 서비스에 보안 이벤트에 대한 액세스 권한을 부여하는 데만 필요합니다. | |
| **`admin:repo_hook`** | |
| 공개, 비공개 또는 내부 리포지토리의 리포지토리 후크에 대한 읽기, 쓰기, ping 및 삭제 권한을 부여합니다. | |
| `repo` 및 `public_repo` 범위는 리포지토리 후크를 포함하여 리포지토리에 대한 모든 권한을 부여합니다. | |
| `admin:repo_hook` 범위를 사용하여 리포지토리 후크로 액세스를 제한합니다. | |
| `write:repo_hook` | |
| 퍼블릭, 프라이빗 또는 내부 리포지토리의 후크에 대한 읽기, 쓰기 및 핑 액세스 권한을 부여합니다. | |
| `read:repo_hook` | |
| 퍼블릭, 프라이빗 또는 내부 리포지토리의 후크에 대한 읽기, 쓰기 및 핑 액세스 권한을 부여합니다. | |
| **`admin:org`** | 조직 및 해당 팀, 프로젝트, 멤버십을 완전히 관리합니다. |
| `write:org` | 조직 멤버십 및 조직 프로젝트에 대한 읽기 및 쓰기 권한입니다. |
| `read:org` | 조직 멤버십, 조직 프로젝트 및 팀 멤버십에 대한 읽기 전용 권한입니다. |
| **`admin:public_key`** | 공개 키를 완전히 관리합니다. |
| `write:public_key` | 공개 키에 대한 세부 정보를 생성하고 나열하며 봅니다. |
| `read:public_key` | 공개 키에 대한 세부 정보를 나열하고 봅니다. |
| **`admin:org_hook`** | 조직 후크에 대한 읽기, 쓰기, ping 및 삭제 권한을 부여합니다. |
| **참고:** OAuth 토큰은 에서 만든 OAuth app조직 후크에서만 이러한 작업을 수행할 수 있습니다. | |
| Personal access tokens는 사용자가 만든 조직 후크에서만 이러한 작업을 수행할 수 있습니다. | |
| **`gist`** | gist에 대한 쓰기 권한을 부여합니다. |
| **`notifications`** | 권한:
사용자의 알림에 대한 읽기 권한
스레드에 대한 읽기 권한으로 표시
리포지토리에 대한 구독 및 구독 취소 권한, 그리고
스레드 구독에 대한 읽기, 쓰기 및 삭제 액세스 권한 |
| **`user`** | 프로필 정보에 대한 읽기/쓰기 권한만 부여합니다. 이 범위에는 `user:email`과 `user:follow`가 포함됩니다. |
| `read:user` | 사용자 프로필 데이터를 읽을 수 있는 액세스 권한을 부여합니다. |
| `user:email` | 사용자의 이메일 주소에 대한 읽기 권한을 부여합니다. |
| `user:follow` | 다른 사용자를 팔로우하거나 팔로우 취소할 수 있는 액세스 권한을 부여합니다. |
| **`delete_repo`** | 관리 가능한 리포지토리 삭제에 대한 액세스 권한을 부여합니다. |
| **`write:packages`** | 에서 패키지를 업로드하거나 게시할 수 있는 액세스 권한을 부여합니다 GitHub Packages. 자세한 내용은 [패키지 게시](/ko/enterprise-server@3.22/packages/learn-github-packages/publishing-a-package)을(를) 참조하세요. |
| **`read:packages`** | 에서 GitHub Packages패키지를 다운로드하거나 설치할 수 있는 액세스 권한을 부여합니다. 자세한 내용은 [패키지 설치](/ko/enterprise-server@3.22/packages/learn-github-packages/installing-a-package)을(를) 참조하세요. |
| **`delete:packages`** | 에서 GitHub Packages패키지를 삭제할 수 있는 액세스 권한을 부여합니다. 자세한 내용은 [패키지 삭제 및 복원](/ko/enterprise-server@3.22/packages/learn-github-packages/deleting-and-restoring-a-package)을(를) 참조하세요. |
| **`admin:gpg_key`** | GPG 키를 완전히 관리합니다. |
| `write:gpg_key` | GPG 키에 대한 세부 정보를 생성하고 나열하며 봅니다. |
| `read:gpg_key` | GPG 키에 대한 세부 정보를 나열하고 봅니다. |
| **`workflow`** | 워크플로 파일을 추가하고 업데이트 GitHub Actions 하는 기능을 부여합니다. 경로와 내용이 모두 동일한 파일이 동일한 리포지토리의 다른 분기에 있는 경우 이 범위 없이 워크플로 파일을 커밋할 수 있습니다. 워크플로 파일은 다른 범위 집합을 포함할 수 있는 `GITHUB_TOKEN`을 노출할 수 있습니다. 자세한 내용은 [워크플로에서 인증에 GITHUB\_TOKEN 사용](/ko/enterprise-server@3.22/actions/tutorials/authenticate-with-github_token#modifying-the-permissions-for-the-github_token)을 참조하세요. |
| **`admin:enterprise`** | 엔터프라이즈 기능의 전체 제어 기능을 제공합니다. 자세한 내용은 GraphQL API 설명서의 [엔터프라이즈 계정 관리](/ko/enterprise-server@3.22/graphql/guides/managing-enterprise-accounts)을(를) 참조하세요.
|
| `manage_runners:enterprise`, `manage_billing:enterprise` 및 `read:enterprise`를 포함합니다. | |
| `manage_runners:enterprise` | 엔터프라이즈 내에서 자체 호스트형 실행기에 대한 전체 제어 기능을 제공합니다. 자세한 내용은 [자체 호스팅 실행기](/ko/enterprise-server@3.22/actions/concepts/runners/self-hosted-runners)을(를) 참조하세요. |
| `manage_billing:enterprise` | 엔터프라이즈 청구 데이터를 읽고 씁니다. 자세한 내용은 [청구에 대한 REST API 엔드포인트](/ko/enterprise-server@3.22/rest/billing)을(를) 참조하세요. |
| `read:enterprise` | 엔터프라이즈 프로필의 모든 데이터를 읽습니다. 엔터프라이즈 구성원 또는 조직의 프로필 데이터는 포함하지 않습니다. |
| **`read:audit_log`** | 감사 로그 데이터를 읽습니다. |
> \[!NOTE]
> OAuth app 초기 리디렉션에서 범위를 요청할 수 있습니다. 다음과 같이 `%20`을 사용하여 여러 범위를 공백으로 구분하여 지정할 수 있습니다.
>
> ```text
> https://github.com/login/oauth/authorize?
> client_id=...&
> scope=user%20repo_deployment
> ```
## 요청된 범위 및 권한 부여된 범위
`scope` 특성에는 사용자가 권한을 부여한 토큰에 연결된 범위가 나열됩니다. 일반적으로 해당 범위는 요청한 범위와 동일합니다.
그러나 사용자는 범위를 편집하여 애플리케이션에 원래 요청한 것보다 적은 액세스 권한을 효과적으로 부여할 수 있습니다. 또한 사용자는 OAuth 흐름이 완료된 후 토큰 범위를 편집할 수 있습니다.
가능성을 인지하고 그에 따라 애플리케이션의 동작을 조정해야 합니다.
사용자가 원래 요청한 것보다 적은 액세스 권한을 부여하는 오류 사례를 처리하는 것이 중요합니다. 예를 들어 애플리케이션은 사용자에게 기능이 축소되거나 일부 작업을 수행할 수 없음을 경고하거나 전달할 수 있습니다.
또한 애플리케이션이 항상 추가 권한을 얻도록 흐름을 통해 사용자를 돌려보낼 수 있지만 사용자는 항상 거절할 수 있다는 것을 잊지 마세요.
수정 가능한 토큰 범위 처리에 대한 팁을 제공하는 [인증의 기본 사항 가이드](/ko/enterprise-server@3.22/apps/oauth-apps/building-oauth-apps/authenticating-to-the-rest-api-with-an-oauth-app)를 확인하세요.
## 정규화된 범위
여러 범위를 요청할 때 토큰은 정규화된 범위 목록과 함께 저장되어 요청된 다른 범위에 암시적으로 포함된 범위를 삭제합니다. 예를 들어`user,gist,user:email`을 요청하면 `user` 범위에서 부여된 액세스가 `gist` 범위에 포함되므로 `user:email` 및 `user` 범위만 있는 토큰이 생성됩니다.