InfoGrab Docs

OAuth 2.0 인증 ID 공급자로 GitLab 구성

요약

OAuth 2.0은 리소스 소유자를 대신하여 클라이언트 애플리케이션에 대한 안전한 위임 서버 리소스 액세스를 제공합니다. 인스턴스에 다음 유형의 OAuth 2 애플리케이션을 추가하여 GitLab을 OAuth 2 인증 ID 공급자로 사용할 수 있습니다:

히스토리

OAuth 2.0은 리소스 소유자를 대신하여 클라이언트 애플리케이션에 대한 안전한 위임 서버 리소스 액세스를 제공합니다. OAuth 2는 인증 서버가 리소스 소유자 또는 최종 사용자의 승인을 받아 제3자 클라이언트에게 액세스 토큰을 발급할 수 있도록 합니다.

인스턴스에 다음 유형의 OAuth 2 애플리케이션을 추가하여 GitLab을 OAuth 2 인증 ID 공급자로 사용할 수 있습니다:

이러한 방법은 권한 수준에 따라만 다릅니다. 기본 콜백 URL은 SSL URL https://your-gitlab.example.com/users/auth/gitlab/callback입니다. 대신 비-SSL URL을 사용할 수 있지만 SSL URL을 사용하는 것이 좋습니다.

인스턴스에 OAuth 2 애플리케이션을 추가한 후 OAuth 2를 사용하여 다음을 수행할 수 있습니다:

  • 사용자가 GitLab.com 계정으로 애플리케이션에 로그인할 수 있도록 합니다.
  • 연결된 그룹에 SAML이 구성된 경우 사용자가 SAML SSO를 사용하여 애플리케이션에 로그인할 수 있도록 합니다.
  • GitLab 인스턴스에 대한 인증을 위해 GitLab.com을 설정합니다. 자세한 내용은 GitLab.com과 서버 통합을 참조하세요.
  • 애플리케이션이 생성된 후 외부 서비스는 OAuth 2 API를 사용하여 액세스 토큰을 관리할 수 있습니다.

사용자 소유 애플리케이션 만들기#

사용자에 대한 새 애플리케이션을 만들려면:

  1. 오른쪽 상단 모서리에서 아바타를 선택하세요.

  2. 프로필 편집을 선택하세요.

  3. 왼쪽 사이드바에서 액세스 > 애플리케이션을 선택하세요.

  4. 새 애플리케이션 추가를 선택하세요.

  5. 이름과 리다이렉트 URI를 입력하세요.

  6. 인증된 애플리케이션에 정의된 OAuth 2 범위를 선택하세요.

  7. 리다이렉트 URI에 GitLab으로 인증한 후 사용자가 보내지는 URL을 입력하세요.

  8. 애플리케이션 저장을 선택하세요. GitLab에서 제공:

    • 애플리케이션 ID 필드의 OAuth 2 클라이언트 ID
    • 시크릿 필드에서 복사를 선택하여 액세스 가능한 OAuth 2 클라이언트 시크릿
    • 시크릿 갱신 기능. 이 기능을 사용하여 이 애플리케이션에 대한 새 시크릿을 생성하고 복사하세요. 시크릿을 갱신하면 자격 증명이 업데이트될 때까지 기존 애플리케이션이 작동하지 않습니다.

그룹 소유 애플리케이션 만들기#

그룹에 대한 새 애플리케이션을 만들려면:

  1. 원하는 그룹으로 이동하세요.

  2. 왼쪽 사이드바에서 설정 > 애플리케이션을 선택하세요.

  3. 이름과 리다이렉트 URI를 입력하세요.

  4. 인증된 애플리케이션에 정의된 OAuth 2 범위를 선택하세요.

  5. 리다이렉트 URI에 GitLab으로 인증한 후 사용자가 보내지는 URL을 입력하세요.

  6. 애플리케이션 저장을 선택하세요. GitLab에서 제공:

    • 애플리케이션 ID 필드의 OAuth 2 클라이언트 ID
    • 시크릿 필드에서 복사를 선택하여 액세스 가능한 OAuth 2 클라이언트 시크릿
    • 시크릿 갱신 기능. 이 기능을 사용하여 이 애플리케이션에 대한 새 시크릿을 생성하고 복사하세요. 시크릿을 갱신하면 자격 증명이 업데이트될 때까지 기존 애플리케이션이 작동하지 않습니다.

인스턴스 전체 애플리케이션 만들기#

사전 요구 사항:

  • 관리자 액세스.

GitLab 인스턴스용 애플리케이션을 만들려면:

  1. 오른쪽 상단 모서리에서 관리를 선택하세요.
  2. In the left sidebar, select Applications.
  3. 새 애플리케이션을 선택하세요.

관리 영역에서 애플리케이션을 만들 때 신뢰할 수 있음으로 표시하세요. 이 애플리케이션에 대한 사용자 인증 단계가 자동으로 건너뜁니다.

모든 인증된 애플리케이션 보기#

히스토리
  • k8s_proxy가 GitLab 16.4에서 k8s_proxy_pat이라는 플래그와 함께 도입되었습니다. 기본적으로 활성화됩니다.
  • 기능 플래그 k8s_proxy_pat이 GitLab 16.5에서 제거되었습니다.

GitLab 자격 증명으로 인증한 모든 애플리케이션을 보려면:

  1. 오른쪽 상단 모서리에서 아바타를 선택하세요.
  2. 프로필 편집을 선택하세요.
  3. 왼쪽 사이드바에서 액세스 > 애플리케이션을 선택하세요.
  4. 인증된 애플리케이션 섹션을 확인하세요.

GitLab OAuth 2 애플리케이션은 애플리케이션이 다양한 작업을 수행할 수 있도록 하는 범위를 지원합니다. 모든 사용 가능한 범위에 대한 다음 표를 참조하세요.

범위 설명
api 컨테이너 레지스트리, 의존성 프록시, 패키지 레지스트리를 포함한 모든 그룹 및 프로젝트를 포함하여 API에 대한 완전한 읽기/쓰기 액세스를 부여합니다.
read_api 컨테이너 레지스트리, 패키지 레지스트리를 포함한 모든 그룹 및 프로젝트를 포함하여 API에 대한 읽기 액세스를 부여합니다.
read_user 사용자 이름, 공개 이메일, 전체 이름을 포함하여 /user API 엔드포인트를 통해 인증된 사용자 프로필에 대한 읽기 전용 액세스를 부여합니다. /users 아래의 읽기 전용 API 엔드포인트에 대한 액세스도 부여합니다.
create_runner 러너에 대한 생성 액세스를 부여합니다.
manage_runner 러너를 관리하는 액세스를 부여합니다.
k8s_proxy Kubernetes 에이전트를 사용하여 Kubernetes API 호출을 수행할 수 있는 권한을 부여합니다.
read_repository Git-over-HTTP 또는 리포지토리 파일 API를 사용하여 비공개 프로젝트의 리포지토리에 대한 읽기 전용 액세스를 부여합니다.
write_repository Git-over-HTTP(API를 사용하지 않고)를 사용하여 비공개 프로젝트의 리포지토리에 대한 읽기-쓰기 액세스를 부여합니다.
read_registry 비공개 프로젝트의 컨테이너 레지스트리 이미지에 대한 읽기 전용 액세스를 부여합니다.
write_registry 비공개 프로젝트의 컨테이너 레지스트리 이미지에 대한 쓰기 액세스를 부여합니다. 이미지를 푸시하려면 읽기 및 쓰기 액세스가 모두 필요합니다.
read_virtual_registry 비공개 프로젝트 및 가상 레지스트리의 의존성 프록시를 통해 컨테이너 이미지에 대한 읽기 전용 액세스를 부여합니다.
write_virtual_registry 비공개 프로젝트의 의존성 프록시를 통해 컨테이너 이미지에 대한 읽기, 쓰기, 삭제 액세스를 부여합니다.
read_observability GitLab Observability에 대한 읽기 전용 액세스를 부여합니다.
write_observability GitLab Observability에 대한 쓰기 액세스를 부여합니다.
ai_features GitLab Duo 관련 API 엔드포인트에 대한 액세스를 부여합니다.
sudo 관리자 사용자로 인증할 때 시스템의 모든 사용자로 API 작업을 수행할 수 있는 권한을 부여합니다.
admin_mode 관리자 모드가 활성화된 경우 관리자로 API 작업을 수행할 수 있는 권한을 부여합니다.
read_service_ping 관리자 사용자로 인증할 때 API를 통해 서비스 핑 페이로드를 다운로드하는 액세스를 부여합니다.
openid OpenID Connect를 사용하여 GitLab으로 인증할 수 있는 권한을 부여합니다. 사용자 프로필 및 그룹 멤버십에 대한 읽기 전용 액세스도 제공합니다.
profile OpenID Connect를 사용하여 사용자 프로필 데이터에 대한 읽기 전용 액세스를 부여합니다.
email OpenID Connect를 사용하여 사용자의 기본 이메일 주소에 대한 읽기 전용 액세스를 부여합니다.

언제든지 취소를 선택하여 모든 액세스를 취소할 수 있습니다.

액세스 토큰 만료#

액세스 토큰은 두 시간 후에 만료됩니다. 액세스 토큰을 사용하는 통합은 refresh_token 속성을 사용하여 새 토큰을 생성해야 합니다. 갱신 토큰은 access_token 자체가 만료된 후에도 사용될 수 있습니다. 만료된 액세스 토큰을 갱신하는 방법에 대한 자세한 내용은 OAuth 2.0 토큰 문서를 참조하세요.

이 만료 설정은 GitLab을 OAuth 공급자 기능으로 제공하는 라이브러리인 Doorkeeper의 access_token_expires_in 구성을 사용하여 GitLab 코드베이스에서 설정됩니다. 만료 설정은 구성할 수 없습니다.

애플리케이션이 삭제되면 애플리케이션과 관련된 모든 권한 및 토큰도 삭제됩니다.

해시된 OAuth 애플리케이션 시크릿#

기본적으로 GitLab은 데이터베이스에 해시 형식으로 OAuth 애플리케이션 시크릿을 저장합니다. 이 시크릿은 OAuth 애플리케이션을 만든 직후에만 사용자가 사용할 수 있습니다. 이전 버전의 GitLab에서는 애플리케이션 시크릿이 데이터베이스에 일반 텍스트로 저장됩니다.

GitLab에서 OAuth 2를 사용하는 다른 방법#

다음을 수행할 수 있습니다:

  • Applications API를 사용하여 OAuth 2 애플리케이션을 만들고 관리하세요.
  • 제3자 OAuth 2 공급자를 사용하여 사용자가 GitLab에 로그인할 수 있도록 합니다. 자세한 내용은 OmniAuth 문서를 참조하세요.
  • GitLab.com 계정에 사용자 자격 증명을 공유하지 않고 리포지토리에 대한 액세스를 제공하기 위해 OAuth 2와 함께 GitLab 가져오기를 사용하세요.

OAuth 2.0 인증 ID 공급자로 GitLab 구성

Tier: Free, Premium, Ultimate
Offering: GitLab Self-Managed
원문 보기
요약

OAuth 2.0은 리소스 소유자를 대신하여 클라이언트 애플리케이션에 대한 안전한 위임 서버 리소스 액세스를 제공합니다. 인스턴스에 다음 유형의 OAuth 2 애플리케이션을 추가하여 GitLab을 OAuth 2 인증 ID 공급자로 사용할 수 있습니다:

히스토리

OAuth 2.0은 리소스 소유자를 대신하여 클라이언트 애플리케이션에 대한 안전한 위임 서버 리소스 액세스를 제공합니다. OAuth 2는 인증 서버가 리소스 소유자 또는 최종 사용자의 승인을 받아 제3자 클라이언트에게 액세스 토큰을 발급할 수 있도록 합니다.

인스턴스에 다음 유형의 OAuth 2 애플리케이션을 추가하여 GitLab을 OAuth 2 인증 ID 공급자로 사용할 수 있습니다:

이러한 방법은 권한 수준에 따라만 다릅니다. 기본 콜백 URL은 SSL URL https://your-gitlab.example.com/users/auth/gitlab/callback입니다. 대신 비-SSL URL을 사용할 수 있지만 SSL URL을 사용하는 것이 좋습니다.

인스턴스에 OAuth 2 애플리케이션을 추가한 후 OAuth 2를 사용하여 다음을 수행할 수 있습니다:

  • 사용자가 GitLab.com 계정으로 애플리케이션에 로그인할 수 있도록 합니다.
  • 연결된 그룹에 SAML이 구성된 경우 사용자가 SAML SSO를 사용하여 애플리케이션에 로그인할 수 있도록 합니다.
  • GitLab 인스턴스에 대한 인증을 위해 GitLab.com을 설정합니다. 자세한 내용은 GitLab.com과 서버 통합을 참조하세요.
  • 애플리케이션이 생성된 후 외부 서비스는 OAuth 2 API를 사용하여 액세스 토큰을 관리할 수 있습니다.

사용자 소유 애플리케이션 만들기#

사용자에 대한 새 애플리케이션을 만들려면:

  1. 오른쪽 상단 모서리에서 아바타를 선택하세요.

  2. 프로필 편집을 선택하세요.

  3. 왼쪽 사이드바에서 액세스 > 애플리케이션을 선택하세요.

  4. 새 애플리케이션 추가를 선택하세요.

  5. 이름과 리다이렉트 URI를 입력하세요.

  6. 인증된 애플리케이션에 정의된 OAuth 2 범위를 선택하세요.

  7. 리다이렉트 URI에 GitLab으로 인증한 후 사용자가 보내지는 URL을 입력하세요.

  8. 애플리케이션 저장을 선택하세요. GitLab에서 제공:

    • 애플리케이션 ID 필드의 OAuth 2 클라이언트 ID
    • 시크릿 필드에서 복사를 선택하여 액세스 가능한 OAuth 2 클라이언트 시크릿
    • 시크릿 갱신 기능. 이 기능을 사용하여 이 애플리케이션에 대한 새 시크릿을 생성하고 복사하세요. 시크릿을 갱신하면 자격 증명이 업데이트될 때까지 기존 애플리케이션이 작동하지 않습니다.

그룹 소유 애플리케이션 만들기#

그룹에 대한 새 애플리케이션을 만들려면:

  1. 원하는 그룹으로 이동하세요.

  2. 왼쪽 사이드바에서 설정 > 애플리케이션을 선택하세요.

  3. 이름과 리다이렉트 URI를 입력하세요.

  4. 인증된 애플리케이션에 정의된 OAuth 2 범위를 선택하세요.

  5. 리다이렉트 URI에 GitLab으로 인증한 후 사용자가 보내지는 URL을 입력하세요.

  6. 애플리케이션 저장을 선택하세요. GitLab에서 제공:

    • 애플리케이션 ID 필드의 OAuth 2 클라이언트 ID
    • 시크릿 필드에서 복사를 선택하여 액세스 가능한 OAuth 2 클라이언트 시크릿
    • 시크릿 갱신 기능. 이 기능을 사용하여 이 애플리케이션에 대한 새 시크릿을 생성하고 복사하세요. 시크릿을 갱신하면 자격 증명이 업데이트될 때까지 기존 애플리케이션이 작동하지 않습니다.

인스턴스 전체 애플리케이션 만들기#

사전 요구 사항:

  • 관리자 액세스.

GitLab 인스턴스용 애플리케이션을 만들려면:

  1. 오른쪽 상단 모서리에서 관리를 선택하세요.
  2. In the left sidebar, select Applications.
  3. 새 애플리케이션을 선택하세요.

관리 영역에서 애플리케이션을 만들 때 신뢰할 수 있음으로 표시하세요. 이 애플리케이션에 대한 사용자 인증 단계가 자동으로 건너뜁니다.

모든 인증된 애플리케이션 보기#

히스토리
  • k8s_proxy가 GitLab 16.4에서 k8s_proxy_pat이라는 플래그와 함께 도입되었습니다. 기본적으로 활성화됩니다.
  • 기능 플래그 k8s_proxy_pat이 GitLab 16.5에서 제거되었습니다.

GitLab 자격 증명으로 인증한 모든 애플리케이션을 보려면:

  1. 오른쪽 상단 모서리에서 아바타를 선택하세요.
  2. 프로필 편집을 선택하세요.
  3. 왼쪽 사이드바에서 액세스 > 애플리케이션을 선택하세요.
  4. 인증된 애플리케이션 섹션을 확인하세요.

GitLab OAuth 2 애플리케이션은 애플리케이션이 다양한 작업을 수행할 수 있도록 하는 범위를 지원합니다. 모든 사용 가능한 범위에 대한 다음 표를 참조하세요.

범위 설명
api 컨테이너 레지스트리, 의존성 프록시, 패키지 레지스트리를 포함한 모든 그룹 및 프로젝트를 포함하여 API에 대한 완전한 읽기/쓰기 액세스를 부여합니다.
read_api 컨테이너 레지스트리, 패키지 레지스트리를 포함한 모든 그룹 및 프로젝트를 포함하여 API에 대한 읽기 액세스를 부여합니다.
read_user 사용자 이름, 공개 이메일, 전체 이름을 포함하여 /user API 엔드포인트를 통해 인증된 사용자 프로필에 대한 읽기 전용 액세스를 부여합니다. /users 아래의 읽기 전용 API 엔드포인트에 대한 액세스도 부여합니다.
create_runner 러너에 대한 생성 액세스를 부여합니다.
manage_runner 러너를 관리하는 액세스를 부여합니다.
k8s_proxy Kubernetes 에이전트를 사용하여 Kubernetes API 호출을 수행할 수 있는 권한을 부여합니다.
read_repository Git-over-HTTP 또는 리포지토리 파일 API를 사용하여 비공개 프로젝트의 리포지토리에 대한 읽기 전용 액세스를 부여합니다.
write_repository Git-over-HTTP(API를 사용하지 않고)를 사용하여 비공개 프로젝트의 리포지토리에 대한 읽기-쓰기 액세스를 부여합니다.
read_registry 비공개 프로젝트의 컨테이너 레지스트리 이미지에 대한 읽기 전용 액세스를 부여합니다.
write_registry 비공개 프로젝트의 컨테이너 레지스트리 이미지에 대한 쓰기 액세스를 부여합니다. 이미지를 푸시하려면 읽기 및 쓰기 액세스가 모두 필요합니다.
read_virtual_registry 비공개 프로젝트 및 가상 레지스트리의 의존성 프록시를 통해 컨테이너 이미지에 대한 읽기 전용 액세스를 부여합니다.
write_virtual_registry 비공개 프로젝트의 의존성 프록시를 통해 컨테이너 이미지에 대한 읽기, 쓰기, 삭제 액세스를 부여합니다.
read_observability GitLab Observability에 대한 읽기 전용 액세스를 부여합니다.
write_observability GitLab Observability에 대한 쓰기 액세스를 부여합니다.
ai_features GitLab Duo 관련 API 엔드포인트에 대한 액세스를 부여합니다.
sudo 관리자 사용자로 인증할 때 시스템의 모든 사용자로 API 작업을 수행할 수 있는 권한을 부여합니다.
admin_mode 관리자 모드가 활성화된 경우 관리자로 API 작업을 수행할 수 있는 권한을 부여합니다.
read_service_ping 관리자 사용자로 인증할 때 API를 통해 서비스 핑 페이로드를 다운로드하는 액세스를 부여합니다.
openid OpenID Connect를 사용하여 GitLab으로 인증할 수 있는 권한을 부여합니다. 사용자 프로필 및 그룹 멤버십에 대한 읽기 전용 액세스도 제공합니다.
profile OpenID Connect를 사용하여 사용자 프로필 데이터에 대한 읽기 전용 액세스를 부여합니다.
email OpenID Connect를 사용하여 사용자의 기본 이메일 주소에 대한 읽기 전용 액세스를 부여합니다.

언제든지 취소를 선택하여 모든 액세스를 취소할 수 있습니다.

액세스 토큰 만료#

액세스 토큰은 두 시간 후에 만료됩니다. 액세스 토큰을 사용하는 통합은 refresh_token 속성을 사용하여 새 토큰을 생성해야 합니다. 갱신 토큰은 access_token 자체가 만료된 후에도 사용될 수 있습니다. 만료된 액세스 토큰을 갱신하는 방법에 대한 자세한 내용은 OAuth 2.0 토큰 문서를 참조하세요.

이 만료 설정은 GitLab을 OAuth 공급자 기능으로 제공하는 라이브러리인 Doorkeeper의 access_token_expires_in 구성을 사용하여 GitLab 코드베이스에서 설정됩니다. 만료 설정은 구성할 수 없습니다.

애플리케이션이 삭제되면 애플리케이션과 관련된 모든 권한 및 토큰도 삭제됩니다.

해시된 OAuth 애플리케이션 시크릿#

기본적으로 GitLab은 데이터베이스에 해시 형식으로 OAuth 애플리케이션 시크릿을 저장합니다. 이 시크릿은 OAuth 애플리케이션을 만든 직후에만 사용자가 사용할 수 있습니다. 이전 버전의 GitLab에서는 애플리케이션 시크릿이 데이터베이스에 일반 텍스트로 저장됩니다.

GitLab에서 OAuth 2를 사용하는 다른 방법#

다음을 수행할 수 있습니다:

  • Applications API를 사용하여 OAuth 2 애플리케이션을 만들고 관리하세요.
  • 제3자 OAuth 2 공급자를 사용하여 사용자가 GitLab에 로그인할 수 있도록 합니다. 자세한 내용은 OmniAuth 문서를 참조하세요.
  • GitLab.com 계정에 사용자 자격 증명을 공유하지 않고 리포지토리에 대한 액세스를 제공하기 위해 OAuth 2와 함께 GitLab 가져오기를 사용하세요.