OAuth app이(가) GitHub의 계정으로 사용자를 식별하려는 경우 앱의 개발자 연락처 정보와 요청되는 특정 데이터 목록이 포함된 페이지가 표시됩니다.
Tip
먼저 사용자 메일 주소를 확인해야 OAuth app에 권한을 부여할 수 있습니다.
OAuth app 액세스
OAuth apps은 GitHub Enterprise Cloud 데이터에 대한 ‘읽기’ 또는 ‘쓰기’ 권한을 가질 수 있습니다.____
- 읽기 권한은 앱이 데이터를 ‘보는’ 것만 허용합니다.__
- 쓰기 권한은 앱이 데이터를 ‘변경’할 수 있도록 합니다.__
Tip
권한 있는 통합을 정기적으로 검토하는 것이 좋습니다. 한동안 사용되지 않은 애플리케이션과 토큰을 제거합니다. 자세한 내용은 "권한 있는 OAuth 앱 검토"을(를) 참조하세요.
OAuth 범위 정보
‘범위’는 OAuth app이 퍼블릭 데이터와 비퍼블릭 데이터에 둘 다 액세스하기 위해 요청할 수 있는 명명된 권한 그룹입니다.__
GitHub Enterprise Cloud와 통합되는 OAuth app을 사용하려는 경우 해당 앱이 어떤 유형의 데이터 액세스 권한이 필요한지 알려줍니다. 앱에 액세스 권한을 부여하면 앱은 데이터를 읽거나 수정하는 등의 작업을 사용자 대신 수행할 수 있습니다. 예를 들어 user:email 범위를 요청하는 앱을 사용하려는 경우 앱은 개인 메일 주소에 대한 읽기 전용 액세스 권한을 갖습니다. 자세한 내용은 OAuth 앱에 대한 범위을(를) 참조하세요.
Note
현재 소스 코드 액세스 범위를 읽기 전용으로 지정할 수는 없습니다.
토큰은 토큰 소유자가 가지고 있는 리소스에 액세스하고 해당 리소스에 대한 작업을 수행하는 동일한 기능을 가지고 있으며, 토큰에 부여된 범위 또는 권한을 통해 추가로 제한됩니다. 토큰은 사용자에게 추가 액세스 기능을 부여할 수 없습니다. 예를 들어 애플리케이션에서 admin:org 범위로 구성된 액세스 토큰을 만들 수 있지만, 애플리케이션 사용자가 조직 소유자 아닌 경우 애플리케이션에 조직에 대한 관리 액세스 권한이 부여되지 않습니다.
사용자/애플리케이션/범위 조합별로 발급되는 토큰은 10개로 제한되며, 시간당 만들어지는 트래픽률 제한은 10개입니다. 애플리케이션이 동일한 사용자 및 동일한 범위에 대해 10개 이상의 토큰을 만드는 경우 동일한 사용자/애플리케이션/범위 조합에서 가장 오래된 토큰이 철회됩니다. 그러나 시간당 트래픽률 제한에 도달하면 가장 오래된 토큰이 철회되지 않습니다. 대신 브라우저 내에서 다시 권한 부여 프롬프트를 트리거하여 사용자에게 앱에 부여하는 권한을 재확인하도록 요청합니다. 앱이 1시간 이내에 사용자로부터 10개의 토큰을 요청할 이유가 거의 없거나 전혀 없는 만큼, 이 프롬프트는 앱 작동 중단의 원인이 되는 잠재적인 무한 루프를 방지하기 위한 것입니다.
요청된 데이터 형식
OAuth apps에서 여러 형식의 데이터를 요청할 수 있습니다.
| 데이터 형식 | 설명 |
|---|---|
| 커밋 상태 | 앱이 커밋 상태를 보고하도록 액세스 권한을 부여할 수 있습니다. 커밋 상태 액세스를 통해 앱은 특정 커밋을 기준으로 빌드가 성공했는지 확인할 수 있습니다. 앱이 코드에 액세스할 수는 없지만 특정 커밋의 상태 정보를 읽고 쓸 수 있습니다. |
| 배포 | 배포 상태 액세스를 통해 앱은 퍼블릭 및 프라이빗 리포지토리에 대한 특정 커밋을 기준으로 배포가 성공했는지 확인할 수 있습니다. 앱이 코드에 액세스할 수는 없습니다. |
| Gists | Gist 액세스를 통해 앱은 퍼블릭 및 비밀 Gist에 모두 읽거나 쓸 수 있습니다. |
| 후크 | 웹후크 액세스를 통해 앱은 사용자가 관리하는 리포지토리의 후크 구성을 읽거나 쓸 수 있습니다. |
| Notifications | 알림 액세스를 통해 앱은 이슈 및 끌어오기 요청의 주석과 같은 GitHub Enterprise Cloud 알림을 읽을 수 있습니다. 그러나 앱이 리포지토리의 항목에 액세스할 수는 없습니다. |
| 조직 및 팀 | 조직 및 팀 액세스를 통해 앱은 조직 및 팀 멤버 자격에 액세스하고 관리할 수 있습니다. |
| 개인 사용자 데이터 | 사용자 데이터에는 사용자 프로필에 있는 정보(예: 이름, 메일 주소, 위치)가 포함됩니다. |
| 리포지토리 | 리포지토리 정보에는 기여자의 이름, 만든 분기 및 리포지토리 내의 실제 파일이 포함됩니다. 앱은 사용자 수준의 퍼블릭 또는 프라이빗 리포지토리에 대한 액세스를 요청할 수 있습니다. |
| 리포지토리 삭제 | 앱은 사용자가 관리하는 리포지토리를 삭제하도록 요청할 수 있지만 코드에 액세스할 수는 없습니다. |
| 프로젝트 | 사용자 및 조직 프로젝트에 대한 액세스 앱은 읽기/쓰기 또는 읽기 전용 액세스를 요청할 수 있습니다. |
업데이트된 권한 요청
OAuth apps은 새 액세스 권한을 요청할 때 현재 권한과 새 권한 간의 차이점을 알려줍니다.
OAuth apps 및 조직
OAuth app에 개인 계정에 대한 권한을 부여하면 멤버로 속해 있는 각 조직에 권한 부여가 미치는 영향도 확인할 수 있습니다.
-
OAuth app 액세스 제한이 ‘있는’ 조직의 경우_ _조직 소유자가 해당 조직에서 사용할 애플리케이션을 승인하도록 요청할 수 있습니다. 조직이 승인하지 않은 애플리케이션은 조직의 퍼블릭 리소스에만 액세스할 수 있습니다. 조직 소유자인 경우 직접 애플리케이션을 승인할 수 있습니다.
-
OAuth app 액세스 제한이 ‘없는’ 조직의 경우 해당 조직의 리소스에 대한 액세스 권한이 애플리케이션에 자동으로 부여됩니다.__ 이런 이유로, 개인 계정 리소스 및 조직 리소스에 대한 액세스를 승인할 OAuth apps을 결정할 때는 주의해야 합니다.
SAML Single Sign-On(SSO)를 사용하는 조직에 속해 있고 과거에 SAML을 통해 인증하여 해당 조직에 대해 연결된 ID를 만든 경우 OAuth app에 권한을 부여할 때마다 각 조직에 대한 활성 SAML 세션이 있어야 합니다.
Note
SAML로 보호되는 조직에 액세스하는 권한이 부여된 OAuth app 또는 GitHub App에 문제가 발생하는 경우 권한이 부여된 GitHub Apps 또는 권한이 부여된 OAuth apps 페이지에서 앱을 해지하고, 조직을 방문하여 활성 SAML 세션을 인증하고 설정한 다음, 앱에 액세스하여 다시 인증해야 할 수도 있습니다.