참고
GitHub App 대신 OAuth app을 빌드하는 것을 고려하세요.
OAuth apps 둘 다 GitHub Apps OAuth 2.0을 사용합니다.
GitHub Apps는 OAuth app처럼 사용자를 대신해 작동하거나 자기 자신으로서 작동할 수 있으며, 이는 사용자 입력이 필요하지 않은 자동화에 유용합니다. GitHub Apps 또한 세분화된 권한을 사용하고, 앱이 액세스할 수 있는 리포지토리를 사용자에게 더 잘 제어하고, 수명이 짧은 토큰을 사용합니다. 자세한 내용은 GitHub 앱과 OAuth 앱 간의 차이점 및 GitHub 앱 만들기 정보을(를) 참조하세요.
GitHub'의 OAuth 구현은 웹 브라우저에 액세스할 수 없는 앱에 대해 표준 권한 부여 코드 부여 유형 및 OAuth 2.0 디바이스 권한 부여 를 지원합니다.
앱을 테스트할 때와 같이 표준 방식으로 앱에 대한 권한을 건너뛰려면 비 웹 애플리케이션 흐름을 사용할 수 있습니다.
OAuth app에 권한을 부여하려면 앱에 가장 적합한 권한 부여 흐름을 고려하세요.
- 웹 애플리케이션 흐름: 브라우저에서 실행되는 표준 OAuth apps 에 대해 사용자에게 권한을 부여하는 데 사용됩니다. (암시적 허용 유형은 지원되지 않습니다.)
- 기기 플로우: CLI 도구와 같은 화면 없는 앱에 사용됩니다.
액세스 토큰 만료
일반 토큰 회전을 적용하고 손상된 토큰의 영향을 줄이려면 만료되는 액세스 토큰을 가져오도록 구성할 OAuth app 수 있습니다. 앱이 만료되는 액세스 토큰을 사용하는 경우 액세스 토큰이 포함된 새로 고침 토큰도 받게 됩니다. 웹 애플리케이션 흐름과 디바이스 흐름 모두 만료 토큰을 지원합니다.
액세스 토큰은 8시간 후에 만료되며 새로 고침 토큰은 사용하지 않고 6개월 후에 만료됩니다. 새로 고침 토큰을 사용하여 새 액세스 토큰 및 새 새로 고침 토큰을 생성할 수 있습니다. 자세한 내용은 새로 고침 토큰을 사용하여 액세스 토큰 새로 고침을 참조하세요.
런타임에 만료되는 토큰 사용 설정
만료되는 토큰 지원을 테스트하고 점진적으로 배포하기 위해, 다른 권한 범위에 더해 offline_access 권한 범위를 요청하면 개별 로그인 시 만료되는 토큰과 새로 고침 토큰을 받도록 선택할 수 있습니다. 범위를 요청하면 앱이 offline_access 만료 토큰을 사용하도록 구성되지 않은 경우에도 만료 액세스 토큰 및 새로 고침 토큰을 받게 됩니다.
앱이 둘 다 GitHub Enterprise ServerGitHub.com지원하는 경우 인스턴스가 아직 만료 토큰을 offline_access 지원하지 않을 수 있으므로 GitHub Enterprise Server 범위에 영향을 주지 않도록 준비해야 합니다. 이 경우 만료되지 않는 토큰은 받지만 새로 고침 토큰은 받지 않으므로, 앱에서 새로 고침 토큰이 항상 반환된다고 가정해서는 안 됩니다.
앱에 만료 토큰 필요
새로 고침 토큰을 사용하여 토큰 만료를 처리하도록 앱을 업데이트한 후에는 앱에 대한 토큰 만료를 전역적으로 강제 적용할 수 있습니다. 이로 인해 모든 새 토큰이 만료 및 새로 고침 토큰으로 발급됩니다. 이 기능을 사용하도록 설정해도 기존 토큰이 만료되지는 않으며 수명이 길어질 수 있습니다. 만료되는 토큰으로 전환하려면 사용자가 다시 로그인하도록 합니다. 앱에 대해 이 설정을 구성하려면 OAuth 앱의 선택적 기능 활성화을 참조하세요.
웹 애플리케이션 흐름
참고
GitHub 앱을 빌드하는 경우에도 OAuth 웹 애플리케이션 흐름을 사용할 수 있지만 설정에는 몇 가지 중요한 차이점이 있습니다. 자세한 내용은 사용자를 대신하여 GitHub 앱으로 인증을(를) 참조하세요.
앱 사용자에게 권한을 부여하는 웹 애플리케이션 흐름은 다음과 같습니다.
- 사용자는 GitHub ID를 요청하도록 리디렉션됩니다.
- 사용자는 GitHub 사이트로 다시 리디렉션됩니다.
- 앱이 사용자의 액세스 토큰을 사용하여 API에 액세스합니다.
1. 사용자의 GitHub ID 요청
GET https://github.com/login/oauth/authorize
이 끝점은 다음 입력 매개 변수를 사용합니다.
| 쿼리 매개 변수 | 유형 | 필수 여부 | 설명 |
|---|---|---|---|
client_id | string | 필수 |
등록 |
| redirect_uri|string |매우 권장| 권한 부여 후에 사용자를 보낼 애플리케이션의 URL입니다.
url 리디렉션에 대한 자세한 내용은 아래를 참조하세요. |
| login | string | 선택 사항| 앱에 로그인하고 권한을 부여하는 데 사용할 특정 계정을 제안합니다. |
| scope|string |컨텍스트 종속| 공백으로 구분되는 범위 목록입니다. 제공되지 않은 경우 scope는 애플리케이션의 범위에 권한을 부여하지 않은 사용자의 빈 목록으로 기본 설정됩니다. 애플리케이션의 범위에 권한을 부여한 사용자의 경우, 사용자에게 범위 목록이 포함된 OAuth 권한 부여 페이지가 표시되지 않습니다. 대신, 이 흐름 단계는 사용자가 애플리케이션에 대해 권한을 부여한 범위 집합으로 자동으로 완료됩니다. 예를 들어 사용자가 이미 웹 흐름을 두 번 수행하고 user 범위의 토큰 하나와 repo 범위의 다른 토큰에 권한을 부여한 경우, scope를 제공하지 않는 세 번째 웹 흐름은 user 및 repo 범위의 토큰을 수신합니다.
offline_access 만료 토큰을 가져오기 위해 범위를 사용하면 범위 동작이 변경되지 않습니다. 이는 일반적인 범위로 repo``user추적되지 않으며 사용되는 경우 추가 프롬프트가 나타나지 않습니다. |
| state | string |매우 권장| 추측할 수 없는 임의 문자열입니다. 교차 사이트 요청 위조 공격에서 보호하는 데 사용됩니다. |
| |
| code_challenge | string | 매우 권장 | PKCE(코드 교환용 증명 키)로 인증 흐름을 보호하는 데 사용됩니다.
code_challenge_method가 포함되면 필수입니다. 클라이언트에서 생성된 임의 문자열의 43자 SHA-256 해시여야 합니다. 이 보안 확장에 대한 자세한 내용은 PKCE RFC를 참조하세요.
| code_challenge_method | string | 매우 권장 | PKCE(코드 교환용 증명 키)로 인증 흐름을 보호하는 데 사용됩니다.
code_challenge가 포함되면 필수입니다.
S256이어야 합니다. plain 코드 챌린지 메서드는 지원되지 않습니다.
| |
| allow_signup|string | 선택 사항 | 인증되지 않은 사용자에게 OAuth 흐름 중에 GitHub 등록하는 옵션이 제공될지 여부입니다. 기본값은 true입니다. 정책에서 등록을 금지할 때 false를 사용합니다. |
| prompt | string | 선택 사항 |
select_account로 설정된 경우 계정 선택기를 강제로 표시합니다. 애플리케이션에 HTTP가 아닌 리디렉션 URI가 있거나 사용자가 로그인한 계정이 여러 개 있는 경우에도 계정 선택기가 표시됩니다. |
현재 CORS 플라이트 전 요청(OPTIONS)은 지원되지 않습니다.
2. 사용자가 GitHub 사이트로 다시 리디렉션됩니다.
사용자가 요청을 수락하면 GitHub code 매개변수에 임시 code 및 state 매개변수에 이전 단계에서 제공한 상태 값을 포함하여 사용자의 사이트로 다시 리디렉션합니다. 임시 코드는 10분 후에 만료됩니다. 상태가 일치하지 않으면 타사에서 요청을 만들었으므로 프로세스를 중단해야 합니다.
이 code를 액세스 토큰으로 교환합니다.
POST https://github.com/login/oauth/access_token
이 끝점은 다음 입력 매개 변수를 사용합니다.
| 매개 변수 이름 | 유형 | 필수 여부 | 설명 |
|---|---|---|---|
client_id | string | 필수 | |
| GitHub에서 OAuth app에 대해 받은 클라이언트 ID입니다. | |||
client_secret | string | 필수 | |
| GitHub에서 받은 OAuth app용 클라이언트 암호입니다. | |||
code | string | 필수 | 1단계에 대한 응답으로 받은 코드입니다. |
redirect_uri | string | 매우 권장 | 권한 부여 후 사용자가 전송되는 애플리케이션의 URL입니다. 이를 사용하여 code가 발급될 때 원래 제공된 URI와 대조하여 서비스에 대한 공격을 방지할 수 있습니다. |
code_verifier | string | 매우 권장 | PKCE(코드 교환용 증명 키)로 인증 흐름을 보호하는 데 사용됩니다. 사용자 권한 부여 중에 code_challenge가 전송된 경우 필수입니다. 권한 부여 요청에서 code_challenge를 생성하는 데 사용된 원래 값이어야 합니다. 이 값은 애플리케이션 아키텍처에 따라 인증 중에 state 매개 변수와 함께 쿠키에 저장되거나 세션 변수에 저장할 수 있습니다. |
기본적으로 응답의 형식은 다음과 같습니다.
access_token=gho_16C7e42F292c6912E7710c838347Ae178B4a
&scope=repo%2Cgist
&token_type=bearer
Accept 헤더에 형식을 제공하는 경우 다른 형식으로 응답을 받을 수도 있습니다. 예를 들어 Accept: application/json 또는 Accept: application/xml입니다.
Accept: application/json
{
"access_token":"gho_16C7e42F292c6912E7710c838347Ae178B4a",
"scope":"repo,gist",
"token_type":"bearer"
}
Accept: application/xml
<OAuth>
<token_type>bearer</token_type>
<scope>repo,gist</scope>
<access_token>gho_16C7e42F292c6912E7710c838347Ae178B4a</access_token>
</OAuth>
OAuth app 만료되는 액세스 토큰을 사용하거나 offline_access 범위를 요청한 경우, 응답에는 refresh_token_expires_in와 함께 각 토큰이 언제 만료되는지를 나타내는 expires_in 및 refresh_token 값(현재 시점으로부터 초 단위)도 포함됩니다. 자세한 내용은 액세스 토큰 만료를 참조하세요.
기본적으로 응답의 형식은 다음과 같습니다.
access_token=gho_16C7e42F292c6912E7710c838347Ae178B4a
&expires_in=28800
&refresh_token=ghr_1B4a2e77838347a7E420ce178F2E7c6912E169246c34E1ccbF66C46812d16D5B1A9Dc86A1498
&refresh_token_expires_in=15897600
&scope=repo%2Cgist
&token_type=bearer
3. 액세스 토큰을 사용하여 API에 액세스
액세스 토큰을 사용하면 사용자를 대신하여 API에 요청할 수 있습니다.
Authorization: Bearer OAUTH-TOKEN
GET https://api.github.com/user
예를 들어 curl에서 다음과 같이 인증 헤더를 설정할 수 있습니다.
curl -H "Authorization: Bearer OAUTH-TOKEN" https://api.github.com/user
액세스 토큰을 받을 때마다 토큰을 사용하여 사용자의 ID 유효성을 다시 검사해야 합니다. 사용자는 앱에 권한을 부여하기 위해 로그인할 때 로그인한 계정을 변경할 수 있으며, 로그인할 때마다 사용자 ID의 유효성을 검사하지 않으면 사용자 데이터가 혼용될 위험이 있습니다.
디바이스 흐름
디바이스 흐름을 사용하면 CLI 도구 또는 Git 자격 증명 관리자와 같은 헤드리스 애플리케이션의 사용자에게 권한을 부여할 수 있습니다.
디바이스 흐름을 사용하여 사용자에게 권한을 부여하고 식별하려면 먼저 앱 설정에서 사용하도록 설정해야 합니다. 앱에서 디바이스 흐름을 사용하도록 설정하는 방법에 대한 자세한 내용은 GitHub 앱 등록 수정GitHub Apps 및 OAuth 앱 수정OAuth apps를 참조하세요.
디바이스 흐름 개요
- 앱은 디바이스 및 사용자 확인 코드를 요청하고 사용자가 사용자 확인 코드를 입력할 권한 부여 URL을 가져옵니다.
- 앱은 사용자에게 사용자 확인 코드를
https://github.com/login/device입력하라는 메시지를 표시합니다. - 앱은 사용자의 인증 상태를 주기적으로 확인합니다. 사용자가 디바이스에 권한을 부여하면 앱은 새 액세스 토큰으로 API 호출을 수행할 수 있습니다.
1단계: 앱이 GitHub 디바이스 및 사용자 확인 코드를 요청합니다.
POST https://github.com/login/device/code
앱은 사용자에게 다음 단계에서 인증하라는 메시지를 표시하는 데 사용할 사용자 확인 코드 및 확인 URL을 요청해야 합니다. 또한 이 요청은 앱이 액세스 토큰을 수신하고 사용자 인증 상태를 확인하는 데 사용해야 하는 디바이스 확인 코드를 반환합니다.
끝점은 다음 입력 매개 변수를 사용합니다.
| 매개 변수 이름 | 유형 | 설명 |
|---|---|---|
client_id | string | |
| 필수입니다. | ||
| GitHub로부터 귀하의 앱용으로 받은 클라이언트 ID입니다. | ||
scope | string | 앱이 액세스를 요청하는 범위의 공백으로 구분된 목록입니다. 자세한 내용은 OAuth 앱에 대한 범위을(를) 참조하세요. |
기본적으로 응답의 형식은 다음과 같습니다.
device_code=3584d83530557fdd1f46af8289938c8ef79f9dc5
&expires_in=900
&interval=5
&user_code=WDJB-MJHT
&verification_uri=https%3A%2F%2Fgithub.com%2Flogin%2Fdevice
| 매개 변수 이름 | 유형 | 설명 |
|---|---|---|
device_code | string | 디바이스 확인 코드는 40자이며 디바이스를 확인하는 데 사용됩니다. |
user_code | string | 사용자가 브라우저에서 코드를 입력할 수 있도록 사용자 확인 코드가 디바이스에 표시됩니다. 이 코드는 8자이며 중간에 하이픈이 있습니다. |
verification_uri | string | 사용자가 다음을 입력해야 하는 확인 URL입니다user_code https:/. |
expires_in | integer | |
device_code 및 user_code의 만료 전 시간(초)입니다. 기본값은 900초(또는 15분)입니다. | ||
interval | integer | 디바이스 권한 부여를 완료하려면 새 액세스 토큰을 요청하기 전에 경과해야 하는 최소 시간(초)입니다(POST https:/). 예를 들어 간격이 5이면 5초가 지나야 새로 요청할 수 있습니다. 5초 동안 두 번 이상 요청하면 속도 제한에 도달하면서 slow_down 오류를 수신합니다. |
Accept 헤더에 형식을 제공하는 경우 다른 형식으로 응답을 받을 수도 있습니다. 예를 들어 Accept: application/json 또는 Accept: application/xml입니다.
Accept: application/json
{
"device_code": "3584d83530557fdd1f46af8289938c8ef79f9dc5",
"user_code": "WDJB-MJHT",
"verification_uri": "https://github.com/login/device",
"expires_in": 900,
"interval": 5
}
Accept: application/xml
<OAuth>
<device_code>3584d83530557fdd1f46af8289938c8ef79f9dc5</device_code>
<user_code>WDJB-MJHT</user_code>
<verification_uri>https://github.com/login/device</verification_uri>
<expires_in>900</expires_in>
<interval>5</interval>
</OAuth>
2단계: 사용자에게 브라우저에서 사용자 코드를 입력하라는 메시지를 표시합니다.
디바이스에 사용자 확인 코드가 표시되고 사용자에게 코드를 https://github.com/login/device입력하라는 메시지가 표시됩니다.
3단계: 앱이 GitHub에 폴링하여 사용자가 디바이스를 승인했는지를 확인합니다.
POST https://github.com/login/oauth/access_token
디바이스 및 사용자 코드가 만료되거나 사용자가 유효한 사용자 코드로 앱에 권한을 성공적으로 부여할 때까지 앱은 POST https://github.com/login/oauth/access_token을 폴링하는 디바이스 권한 부여 요청을 합니다. 앱이 속도 제한 오류를 방지하려면 1단계에서 검색된 최소 폴링 interval을 사용해야 합니다. 자세한 내용은 디바이스 흐름에 대한 속도 제한을 참조하세요.
사용자는 15분(또는 900초) 이내에 유효한 코드를 입력해야 합니다. 15분이 지나면 POST https://github.com/login/device/code를 사용하여 새 디바이스 권한 부여 코드를 요청해야 합니다.
사용자가 권한을 부여하면 앱은 사용자를 대신하여 API에 요청하는 데 사용할 수 있는 액세스 토큰을 받게 됩니다.
끝점은 다음 입력 매개 변수를 사용합니다.
| 매개 변수 이름 | 유형 | 설명 |
|---|---|---|
client_id | string | |
| 필수입니다. | ||
| GitHub에서 OAuth app에 대해 받은 클라이언트 ID입니다. | ||
device_code | string | |
| 필수입니다. | ||
device_code 요청에서 받은 POST https:/입니다. | ||
grant_type | string | |
필수입니다. 권한 부여 유형은 urn:ietf:params:oauth:grant-type:device_이어야 합니다. |
기본적으로 응답의 형식은 다음과 같습니다.
access_token=gho_16C7e42F292c6912E7710c838347Ae178B4a
&token_type=bearer
&scope=repo%2Cgist
Accept 헤더에 형식을 제공하는 경우 다른 형식으로 응답을 받을 수도 있습니다. 예를 들어 Accept: application/json 또는 Accept: application/xml입니다.
Accept: application/json
{
"access_token": "gho_16C7e42F292c6912E7710c838347Ae178B4a",
"token_type": "bearer",
"scope": "repo,gist"
}
Accept: application/xml
<OAuth>
<access_token>gho_16C7e42F292c6912E7710c838347Ae178B4a</access_token>
<token_type>bearer</token_type>
<scope>gist,repo</scope>
</OAuth>
OAuth app에서 만료되는 액세스 토큰을 사용하거나 offline_access 범위를 요청한 경우, 응답에는 refresh_token와 함께 각 토큰이 만료되는 시점을 나타내는 refresh_token_expires_in 및 expires_in 값도 포함됩니다. 자세한 내용은 액세스 토큰 만료를 참조하세요.
access_token=gho_16C7e42F292c6912E7710c838347Ae178B4a
&expires_in=28800
&refresh_token=ghr_1B4a2e77838347a7E420ce178F2E7c6912E169246c34E1ccbF66C46812d16D5B1A9Dc86A1498
&refresh_token_expires_in=15897600
&token_type=bearer
&scope=repo%2Cgist
디바이스 흐름의 속도 제한
사용자가 브라우저에서 확인 코드를 제출하는 경우 애플리케이션당 1시간에 50개의 제출 속도 제한이 있습니다.
요청 간에 필요한 최소 기간 내(또는 POST https://github.com/login/oauth/access_token)에 둘 이상의 액세스 토큰 요청(interval)을 하는 경우 속도 제한에 도달하고 slow_down 오류 응답을 수신하게 됩니다.
slow_down 오류 응답은 마지막 interval에 5초를 추가합니다. 자세한 내용은 디바이스 흐름의 오류 코드를 참조하세요.
디바이스 흐름의 오류 코드
| 오류 코드 | 설명 |
|---|---|
authorization_ | 이 오류는 권한 부여 요청이 보류 중이고 사용자가 사용자 코드를 아직 입력하지 않은 경우에 발생합니다. 앱은 각 요청 사이에 최소 시간(초)이 필요한 POST https:/을 초과하지 않고 interval 요청을 계속 폴링할 것으로 예상됩니다. |
slow_down | |
slow_down 오류를 수신하는 경우 interval을 사용하여 요청 간 필요한 최소 POST https:/ 또는 기간에 5초가 더 추가됩니다. 예를 들어 시작 간격이 요청 사이에 5초 이상 필요하고 slow_down 오류 응답을 수신하는 경우 OAuth 액세스 토큰을 새로 요청하기 전에 최소 10초 동안 기다려야 합니다. 오류 응답에는 사용해야 하는 새 interval이 포함됩니다. | |
expired_token | 디바이스 코드가 만료되면 token_expired 오류가 표시됩니다. 이 경우 디바이스 코드를 새로 요청해야 합니다. |
unsupported_grant_ | OAuth 토큰 요청 urn:ietf:params:oauth:grant-type:device_을 폴링할 때 권한 부여 형식은 POST https:/이며 입력 매개 변수로 포함되어야 합니다. |
incorrect_client_ | 디바이스 흐름의 경우 앱 설정 페이지에서 찾을 수 있는 앱의 클라이언트 ID를 전달해야 합니다. |
client_secret은 디바이스 흐름에 필요하지 않습니다. | |
incorrect_device_ | 제공된 device_code는 잘못되었습니다. |
access_denied | 권한 부여 프로세스 중에 사용자가 취소를 클릭하면 access_denied 오류를 수신하게 되고 사용자는 확인 코드를 다시 사용할 수 없습니다. |
device_flow_disabled | 앱 설정에서 디바이스 흐름을 사용하도록 설정하지 않았습니다. 자세한 내용은 디바이스 흐름을 참조하세요. |
자세한 내용은 OAuth 2.0 디바이스 권한 부여를 참조하세요.
새로 고침 토큰을 사용하여 액세스 토큰 새로 고침
OAuth app 만료 액세스 토큰을 사용하는 경우 새로 고침 토큰을 사용하여 새 액세스 토큰과 새 새로 고침 토큰을 생성할 수 있습니다. 새로 고침 토큰을 사용하면 새로 고침 토큰과 이전 액세스 토큰이 더 이상 작동하지 않습니다. 토큰 만료에 대한 자세한 내용은 액세스 토큰 만료를 참조하세요.
새로 고침 토큰을 사용하기 전에 만료되는 경우 새 토큰 쌍을 가져오려면 웹 애플리케이션 흐름 또는 디바이스 흐름을 통해 사용자를 다시 보내야 합니다.
액세스 토큰 POST 을 새로 고치려면 아래 입력 매개 변수와 함께 다음 URL을 요청합니다.
POST https://github.com/login/oauth/access_token
| 매개 변수 이름 | 유형 | 필수 여부 | 설명 |
|---|---|---|---|
client_id | string | 필수 | |
| GitHub에서 OAuth app에 대해 받은 클라이언트 ID입니다. | |||
client_secret | string | 디바이스 흐름을 사용하여 토큰을 생성하지 않는 한 필수 | |
| GitHub에서 받은 OAuth app용 클라이언트 암호입니다. | |||
grant_type | string | 필수 | 값은 refresh_token여야 합니다. |
refresh_token | string | 필수 | 액세스 토큰을 생성할 때 받은 새로 고침 토큰입니다. |
기본적으로 응답의 형식은 다음과 같습니다.
access_token=gho_16C7e42F292c6912E7710c838347Ae178B4a
&expires_in=28800
&refresh_token=ghr_1B4a2e77838347a7E420ce178F2E7c6912E169246c34E1ccbF66C46812d16D5B1A9Dc86A1498
&refresh_token_expires_in=15897600
&scope=repo%2Cgist
&token_type=bearer
새 액세스 토큰의 범위는 이전 토큰의 범위와 일치합니다. 결과 토큰의 scope 액세스를 변경하기 위해 토큰을 새로 고치는 동안 매개 변수를 제공할 수 없습니다.
지정한 새로 고침 토큰이 잘못되었거나 만료된 경우 bad_refresh_token 오류가 발생합니다. 이 오류를 해결하려면 웹 애플리케이션 흐름 또는 디바이스 흐름을 통해 사용자를 다시 보내 새 액세스 토큰을 가져오고 토큰을 새로 고칩니다.
비 웹 애플리케이션 흐름
비 웹 인증은 테스트와 같은 제한된 상황에서 사용할 수 있습니다. 필요한 경우 기본 인증을 사용하여 personal access token에서 personal access token을 만들 수 있습니다. 이 방법으로 사용자는 언제든지 액세스를 철회할 수 있습니다.
리디렉션 URL
redirect_uri 매개 변수는 선택 사항입니다.
GitHub를 생략하면 사용자는 OAuth app에 구성된 첫 번째 콜백 URL로 리디렉션됩니다.
설정.
필요한 경우 콜백 URL에 와일드카드 일치를 사용하도록 설정할 수 있습니다. 와일드카드 일치를 사용하도록 설정하면 리디렉션 URL의 호스트(하위 도메인 제외) 및 포트가 콜백 URL과 정확히 일치해야 하며 리디렉션 URL의 경로는 콜백 URL의 하위 디렉터리를 참조해야 합니다. 즉, 콜백 URL의 하위 도메인 또는 하위 디렉터리가 일치하여 콜백 URL로 허용됩니다. 예를 들어 콜백 URL https://example.com/path에 와일드카드 일치를 사용하는 경우:
CALLBACK: https://example.com/path
MATCH: https://example.com/path
MATCH: https://example.com/path/subdir/other
MATCH: https://oauth.example.com/path
MATCH: https://oauth.example.com/path/subdir/other
FAIL: https://example.com/bar
FAIL: https://example.com/
FAIL: https://example.com:8080/path
FAIL: https://oauth.example.com:8080/path
FAIL: https://example.org
와일드카드 일치를 사용하지 않도록 설정하면 리디렉션 URL이 콜백 URL과 정확히 일치해야 합니다. 앱 설정의 각 콜백 URL에 대해 와일드카드 일치를 사용하거나 사용하지 않도록 설정할 수 있습니다.
경고
와일드카드 일치를 사용하도록 설정하면 공격자가 콜백 URL의 하위 도메인 또는 하위 디렉터리에 권한 부여 코드를 보낼 수 있으므로 앱이 보안 위험에 노출될 수 있습니다. 반드시 필요한 경우에만 와일드카드 일치를 사용하도록 설정하고 콜백 URL의 가능한 모든 하위 도메인 및 경로를 제어한다고 완전히 확신합니다. 자세한 내용은 OAuth 2.0 보안 모범 사례입니다.
2026년 8월 3일 이전에 단일 콜백 URL을 사용하도록 설정된 앱에는 해당 콜백 URL에 대해 와일드카드 일치가 활성화되어 있습니다. 이렇게 하면 와일드카드 일치가 구성 가능한 설정이 되기 전에 존재했던 리디렉션 동작이 유지되며, 해당 날짜 이전에 생성된 모든 OAuth apps 항목과 일부 GitHub Apps 와일드카드 일치가 사용하도록 설정된 이유입니다. 앱에 와일드카드 일치가 필요하지 않은 경우 사용하지 않도록 설정하는 것이 좋습니다.
루프백 리디렉션 URL
선택적 redirect_uri 매개 변수는 데스크톱 컴퓨터에서 실행되는 원시 애플리케이션에 유용한 루프백 URL에도 사용할 수 있습니다. 애플리케이션이 루프백 URL 및 포트를 지정하는 경우 애플리케이션에 권한을 부여한 후 사용자는 제공된 URL 및 포트로 리디렉션됩니다.
redirect_uri은 앱의 콜백 URL에 지정된 포트와 일치할 필요가 없습니다.
http://127.0.0.1/path 콜백 URL의 경우 애플리케이션이 redirect_uri 포트에서 수신 대기 중이면 해당 1234을(를) 사용할 수 있습니다.
http://127.0.0.1:1234/path
OAuth RFC는 localhost을 사용하지 않고, 대신 루프백 리터럴 또는 IPv6 127.0.0.1을 사용할 것을 권장합니다.
에 대한 여러 토큰 만들기 OAuth apps
사용자/애플리케이션/범위 조합에 여러 토큰을 만들어 특정 사용 사례를 위한 토큰을 만들 수 있습니다.
로그인에 GitHub 사용하고 기본 사용자 정보만 필요한 워크플로 하나를 지원하는 경우에 OAuth app 유용합니다. 다른 워크플로에서는 사용자의 프라이빗 리포지토리에 액세스해야 할 수 있습니다. 여러 토큰을 사용하면 OAuth app는 각 사용 사례에 대해 웹 플로우를 수행하면서 필요한 권한 범위만 요청할 수 있습니다. 사용자가 로그인할 때만 귀하의 애플리케이션을 사용하는 경우, 귀하의 OAuth app에 비공개 리포지토리에 대한 액세스 권한을 부여할 필요가 전혀 없습니다.
사용자/애플리케이션/범위 조합별로 발급되는 토큰은 10개로 제한되며, 시간당 만들어지는 트래픽률 제한은 10개입니다. 애플리케이션이 동일한 사용자 및 동일한 범위에 GitHub 대해 10개 이상의 토큰을 만드는 경우 동일한 사용자/애플리케이션/범위 조합이 있는 기존 토큰 중 하나를 다음 순서로 선택하여 해지합니다.
- 사용된 적이 없으며 1분 이상 전에 만들어진 가장 오래된 토큰입니다. 마지막 순간에 만든 토큰은 일반적으로 보호되므로 애플리케이션에서 방금 만든 토큰을 사용할 시간이 있습니다.
- 이러한 토큰이 없지만 하나 이상의 토큰이 사용된 경우 가장 최근에 사용된 토큰입니다.
- 토큰이 사용된 적이 없는 경우 마지막 1분 내에 만들어진 경우에도 가장 오래된 토큰입니다.
시간당 속도 제한을 초과하면 가장 오래된 토큰이 해지되지 않습니다. 대신 브라우저 내에서 다시 권한 부여 프롬프트를 트리거하여 사용자에게 앱에 부여하는 권한을 재확인하도록 요청합니다. 앱이 1시간 이내에 사용자로부터 10개의 토큰을 요청할 이유가 거의 없거나 전혀 없는 만큼, 이 프롬프트는 앱 작동 중단의 원인이 되는 잠재적인 무한 루프를 방지하기 위한 것입니다.
경고
OAuth app에서 모든 권한을 취소하면 배포 키를 포함하여 애플리케이션이 사용자를 대신하여 생성한 모든 SSH 키가 삭제됩니다.
사용자에게 액세스 권한을 검토하도록 지시
사용자가 애플리케이션에 부여한 권한을 검토하고 철회할 수 있도록 OAuth app의 권한 정보로 연결할 수 있습니다.
이 링크를 생성하려면 애플리케이션을 등록할 때 GitHub에서 받은 OAuth app의 client_id이(가) 필요합니다.
https://github.com/settings/connections/applications/:client_id
팁
사용자에 대해 액세스할 수 있는 OAuth app 리소스에 대한 자세한 내용은 사용자에 대한 리소스 검색을 참조하세요.