# REST API에 인증

REST API에 인증하여 더 많은 엔드포인트에 액세스하고 더 높은 속도 제한을 가질 수 있습니다.

## 인증 정보

인증된 경우 많은 REST API 엔드포인트에 인증이 필요하거나 추가 정보를 반환해야 합니다. 또한 인증 시 시간당 더 많은 요청을 수행할 수 있습니다.

요청을 인증하려면 필요한 범위 또는 권한이 포함된 인증 토큰을 제공해야 합니다. 토큰을 얻는 몇 가지 방법이 있습니다: personal access token을(를) 생성하거나, GitHub App로 토큰을 생성하거나, `GITHUB_TOKEN` 워크플로에서 내장된 GitHub Actions을(를) 사용할 수 있습니다.

토큰을 생성한 후 요청의 `Authorization` 헤더에 토큰을 전송하여 요청을 인증할 수 있습니다. 예를 들어 다음 요청에서 `YOUR-TOKEN`을 해당 토큰에 대한 참조로 바꿉니다.

```shell
curl --request GET \
--url "https://api.github.com/octocat" \
--header "Authorization: Bearer YOUR-TOKEN" \
--header "X-GitHub-Api-Version: 2026-03-10"
```

> \[!NOTE]
> 대부분의 경우 `Authorization: Bearer` 또는 `Authorization: token`을 사용하여 전달할 수 있습니다. 그러나 JWT(JSON 웹 토큰)를 전달하는 경우 `Authorization: Bearer`를 사용해야 합니다.

### 실패한 로그인 제한

토큰 없이 또는 권한이 부족한 토큰으로 REST API 엔드포인트를 사용하려고 하면 `404 Not Found` 또는 `403 Forbidden` 응답을 받게 됩니다. 잘못된 자격 증명으로 인증하면 `401 Unauthorized` 응답이 반환됩니다.

짧은 기간 내에 잘못된 자격 증명을 사용한 여러 요청을 검색하면 API는 `403 Forbidden` 응답을 나타내며 해당 사용자에 대한 모든 인증 시도(유효한 자격 증명을 사용한 시도 포함)를 일시적으로 거부합니다. 자세한 내용은 [REST API에 대한 트래픽률 제한](/ko/rest/using-the-rest-api/rate-limits-for-the-rest-api)을(를) 참조하세요.

## personal access token를 사용하여 인증하기

개인 용도로 REST API를 GitHub 사용하려는 경우, personal access token를 만들 수 있습니다. 가능하다면 GitHubfine-grained personal access token 대신 personal access token (classic)을 사용하는 것이 좋습니다. 자세한 내용은 personal access token 만들기에 대해 [개인용 액세스 토큰 관리](/ko/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens)을 참조하세요.

fine-grained personal access token를 사용하는 경우 각 REST API 엔드포인트에 액세스하려면 fine-grained personal access token에 특정 권한이 필요합니다. 각 엔드포인트에 대한 REST API 참조 문서는 엔드포인트가 s와 함께 fine-grained personal access token작동하는지 여부를 명시하고 토큰이 엔드포인트를 사용하기 위해 필요한 권한을 명시합니다. 일부 엔드포인트에는 여러 권한이 필요할 수 있으며 일부 엔드포인트에는 여러 권한 중 하나가 필요할 수 있습니다. 각 권한으로 액세스할 수 있는 REST API 엔드포인트에 대한 fine-grained personal access token 개요는 [세분화된 개인용 액세스 토큰에 필요한 권한](/ko/rest/authentication/permissions-required-for-fine-grained-personal-access-tokens)을 참조하세요.

사용하는 personal access token (classic)경우 각 REST API 엔드포인트에 액세스하려면 특정 범위가 필요합니다. 선택할 범위에 대한 일반적인 지침은 [OAuth 앱에 대한 범위](/ko/apps/oauth-apps/building-oauth-apps/scopes-for-oauth-apps#available-scopes)을(를) 참조하세요.

Personal access tokens REST API를 요청할 때 ID로 작동합니다(선택한 범위 또는 사용 권한에 의해 제한됨). 따라서 personal access tokens을 안전하게 유지하는 것이 중요합니다. 보안을 유지하는 방법에 대한 자세한 내용은 personal access tokens을 참조하세요[](/ko/rest/authentication/keeping-your-api-credentials-secure?apiVersion=2022-11-28).

### Personal access tokens 및 SAML SSO

인증을 personal access token (classic) 위해 SAML SSO(Single Sign-On)를 적용하는 조직에 액세스하는 데 사용하는 경우 생성 후 토큰에 권한을 부여해야 합니다.
Fine-grained personal access tokens는 조직에 대한 액세스 권한이 부여되기 전에 토큰 생성 중에 승인됩니다. 자세한 내용은 [Single Sign-On에 사용할 개인용 액세스 토큰 권한 부여](/ko/authentication/authenticating-with-single-sign-on/authorizing-a-personal-access-token-for-use-with-single-sign-on)을(를) 참조하세요.

personal access token (classic)에 대해 SAML SSO를 승인하지 않은 상태에서 이를 SAML SSO를 적용하는 단일 조직에 액세스하는 데 사용하려고 하면 `404 Not Found` 또는 `403 Forbidden` 오류가 발생할 수 있습니다.
`403 Forbidden` 오류가 발생하면 `X-GitHub-SSO` 헤더에 토큰 권한을 부여하기 위해 따를 수 있는 URL이 포함됩니다. URL은 1시간 후에 만료됩니다.

SAML SSO를 사용하여 여러 조직에 액세스하기 전에 권한을 부여 personal access token (classic) 하지 않으면 API는 SAML SSO `X-GitHub-SSO` 가 필요한 조직의 결과를 반환하지 않으며 헤더는 사용자의 SAML SSO 권한 부여 personal access token (classic)가 필요한 조직의 ID를 나타냅니다. 예: `X-GitHub-SSO: partial-results; organizations=21955855,20582480`.

## 앱에서 생성한 토큰으로 인증

조직을 위해 또는 다른 사용자를 대신하여 API를 사용하려는 경우, GitHub에서는 GitHub App 사용을 권장합니다. 자세한 내용은 [GitHub 앱을 사용한 인증 정보](/ko/apps/creating-github-apps/authenticating-with-a-github-app/about-authentication-with-a-github-app)을(를) 참조하세요.

각 엔드포인트에 대한 REST API 참조 설명서는 엔드포인트가 작동하는지 GitHub Apps 여부를 명시하고 앱이 엔드포인트를 사용하기 위해 필요한 권한을 명시합니다. 일부 엔드포인트에는 여러 권한이 필요할 수 있으며 일부 엔드포인트에는 여러 권한 중 하나가 필요할 수 있습니다. 각 권한으로 액세스할 수 있는 REST API 엔드포인트에 대한 GitHub App 개요는 [GitHub 앱에 필요한 권한](/ko/rest/authentication/permissions-required-for-github-apps)을 참조하세요.

REST API에 액세스하는 OAuth 토큰을 OAuth app 만들 수도 있습니다. 그러나 GitHub 대신 사용하는 GitHub App 것이 좋습니다.
GitHub Apps 를 사용하면 앱에 있는 액세스 및 권한을 더 많이 제어할 수 있습니다.

앱에서 만든 액세스 토큰은 SAML SSO에 대해 자동으로 권한이 부여됩니다.

### 기본 인증 사용

일부 REST API 엔드포인트는 GitHub AppsOAuth apps 기본 인증을 사용하여 엔드포인트에 액세스해야 합니다. 앱의 클라이언트 ID를 사용자 이름으로 사용하고 앱의 클라이언트 암호를 암호로 사용합니다.

예시:

```shell
curl --request POST \
--url "https://api.github.com/applications/YOUR_CLIENT_ID/token" \
--user "YOUR_CLIENT_ID:YOUR_CLIENT_SECRET" \
--header "Accept: application/vnd.github+json" \
--header "X-GitHub-Api-Version: 2026-03-10" \
--data '{
  "access_token": "ACCESS_TOKEN_TO_CHECK"
}'
```

클라이언트 ID 및 클라이언트 암호는 앱 소유자 또는 앱에 권한을 부여한 사용자가 아닌 앱과 연결됩니다. 액세스 토큰 만들기와 같은 앱을 대신하여 작업을 수행하는 데 사용됩니다.

GitHub App 소유자이거나 OAuth app앱 관리자GitHub App인 경우 클라이언트 ID를 찾아 앱의 설정 페이지에서 클라이언트 암호를 생성할 수 있습니다. 앱의 설정 페이지로 이동하려면 다음을 수행합니다.

1. 페이지의 오른쪽 위 모서리의 GitHub 프로필 사진을 클릭합니다.
2. 계정 설정으로 이동합니다.
   * 개인 계정 소유한 앱의 경우 **설정**을 클릭합니다.
   * 조직이 소유한 앱의 경우:
     1\.
     **내 조직**을 클릭합니다.
     1. 그런 다음, 조직 오른쪽에 있는 **설정**을 클릭합니다.
3. 왼쪽 사이드바에서 **<svg version="1.1" width="16" height="16" viewBox="0 0 16 16" class="octicon octicon-code" aria-label="code" role="img"><path d="m11.28 3.22 4.25 4.25a.75.75 0 0 1 0 1.06l-4.25 4.25a.749.749 0 0 1-1.275-.326.749.749 0 0 1 .215-.734L13.94 8l-3.72-3.72a.749.749 0 0 1 .326-1.275.749.749 0 0 1 .734.215Zm-6.56 0a.751.751 0 0 1 1.042.018.751.751 0 0 1 .018 1.042L2.06 8l3.72 3.72a.749.749 0 0 1-.326 1.275.749.749 0 0 1-.734-.215L.47 8.53a.75.75 0 0 1 0-1.06Z"></path></svg> Developer settings**를 클릭합니다.
4. 왼쪽 사이드바에서 클릭 **GitHub Apps** 하거나 **OAuth apps**.
5. 액세스하려는 GitHub Apps의 오른쪽에 있는 GitHub App에서 **편집**을 클릭합니다. 의 경우 OAuth apps액세스하려는 앱을 클릭합니다.
6. **클라이언트 ID** 옆에 앱의 클라이언트 ID가 표시됩니다.
7. **클라이언트 비밀** 옆에 있는 **새 클라이언트 암호 생성**을 클릭하여 앱에 대한 클라이언트 비밀을 생성합니다.

## GitHub Actions 워크플로에서 인증하기

워크플로 GitHub Actions 에서 API를 GitHub 사용하려면 토큰을 만드는 대신 기본 제공 `GITHUB_TOKEN` 으로 인증하는 것이 좋습니다.
`GITHUB_TOKEN` 키를 사용하여 `permissions`에 대한 사용 권한을 부여할 수 있습니다. 자세한 내용은 [워크플로에서 인증에 GITHUB\_TOKEN 사용](/ko/actions/tutorials/authenticate-with-github_token#modifying-the-permissions-for-the-github_token)을(를) 참조하세요.

가능하지 않은 경우 토큰을 비밀로 저장하고 워크플로에서 비밀의 이름을 사용할 수 있습니다 GitHub Actions . 비밀에 대한 자세한 내용은 [GitHub Actions에서 비밀 사용](/ko/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets)을(를) 참조하세요.

### GitHub Actions를 사용하여 GitHub CLI 워크플로에서 인증하기

GitHub Actions을 사용하여 GitHub CLI 워크플로에서 API에 인증된 요청을 하려면 `GITHUB_TOKEN`의 값을 환경 변수로 저장하고 `run` 키워드를 사용하여 GitHub CLI`api` 하위 명령을 실행할 수 있습니다.
`run` 키워드에 대한 자세한 내용은 [GitHub Actions에 대한 워크플로 구문](/ko/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepsrun)을(를) 참조하세요.

다음 예제 워크플로에서 `PATH`를 엔드포인트의 경로로 바꿉니다. 경로에 대한 자세한 내용은 [REST API 시작](/ko/rest/using-the-rest-api/getting-started-with-the-rest-api?tool=cli#path)을 참조하세요.

```yaml
jobs:
  use_api:
    runs-on: ubuntu-latest
    permissions: {}
    steps:
      - env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          gh api /PATH
```

### `curl`을 사용하여 GitHub Actions 워크플로에서 인증하기

`curl`를 사용하는 GitHub Actions 워크플로에서 API에 인증된 요청을 하려면 `GITHUB_TOKEN`의 값을 환경 변수로 저장하고, `run` 키워드를 사용하여 API에 `curl` 요청을 실행할 수 있습니다.
`run` 키워드에 대한 자세한 내용은 [GitHub Actions에 대한 워크플로 구문](/ko/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepsrun)을(를) 참조하세요.

다음 예제 워크플로에서 `PATH`를 엔드포인트의 경로로 바꿉니다. 경로에 대한 자세한 내용은 [REST API 시작](/ko/rest/using-the-rest-api/getting-started-with-the-rest-api?tool=cli#path)을 참조하세요.

```yaml copy
jobs:
  use_api:
    runs-on: ubuntu-latest
    permissions: {}
    steps:
      - env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          curl --request GET \
          --url "https://api.github.com/PATH" \
          --header "Authorization: Bearer $GH_TOKEN"
```

### JavaScript를 사용하여 GitHub Actions 워크플로에서 인증하기

JavaScript를 사용하여 워크플로에서 인증하는 방법의 예는 GitHub Actions[REST API 및 JavaScript를 사용하여 스크립팅](/ko/rest/guides/scripting-with-the-rest-api-and-javascript#authenticating-in-github-actions)을 참조하세요.

## 사용자 이름 및 암호를 사용하여 인증

사용자 이름 및 암호를 사용한 인증증은 지원되지 않습니다. 사용자 이름 및 암호로 인증하려고 하면 4xx 오류가 발생합니다.

## 추가 참고 자료

* [해당 API 자격 증명 보안 유지](/ko/rest/authentication/keeping-your-api-credentials-secure)
* [REST API 시작](/ko/rest/using-the-rest-api/getting-started-with-the-rest-api#authentication)