GitLab을 OAuth 2.0 인증 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 계정으로 애플리케이션에 로그인할 수 있도록 허용합니다.

  • GitLab.com을 설정하여 GitLab 인스턴스에 대한 인증을 수행합니다. 자세한 내용은 서버와 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 클라이언트 비밀.
    • GitLab 15.9 및 이후 버전에서 제공하는 비밀 갱신 기능. 이 기능을 사용하여 이 애플리케이션에 대한 새 비밀을 생성하고 복사합니다. 비밀을 갱신하면 기존 애플리케이션이 작동하지 않게 되어 자격 증명이 업데이트될 때까지 기능하지 않게 됩니다.

그룹 소유 애플리케이션 생성하기

그룹을 위한 새 애플리케이션을 생성하려면:

  1. 원하는 그룹으로 이동합니다.
  2. 왼쪽 사이드바에서 설정 > 애플리케이션을 선택합니다.
  3. 이름과 리디렉션 URI를 입력합니다.
  4. 권한 부여된 애플리케이션에서 정의된 OAuth 2 범위를 선택합니다.
  5. 리디렉션 URI에 사용자가 GitLab에서 인증한 후 전송되는 URL을 입력합니다.

  6. 애플리케이션 저장을 선택합니다. GitLab은 다음을 제공합니다:

    • 애플리케이션 ID 필드의 OAuth 2 클라이언트 ID.
    • 비밀 필드에서 복사 선택하여 접근할 수 있는 OAuth 2 클라이언트 비밀.
    • GitLab 15.9 및 이후 버전에서 제공하는 비밀 갱신 기능. 이 기능을 사용하여 이 애플리케이션에 대한 새 비밀을 생성하고 복사합니다. 비밀을 갱신하면 기존 애플리케이션이 작동하지 않게 되어 자격 증명이 업데이트될 때까지 기능하지 않게 됩니다.

인스턴스 전체 애플리케이션 생성

Tier: Free, Premium, Ultimate Offering: Self-managed

GitLab 인스턴스에 애플리케이션을 생성하려면:

  1. 왼쪽 사이드바에서 하단의 Admin을 선택합니다.
  2. Applications을 선택합니다.
  3. New application을 선택합니다.

Admin 영역에서 애플리케이션을 생성할 때 이를 trusted로 표시합니다.
이 애플리케이션에 대한 사용자 권한 부여 단계는 자동으로 건너뜁니다.

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

  • k8s_proxy는 GitLab 16.4에서 소개됨 플래그 명칭 k8s_proxy_pat과 함께. 기본적으로 활성화되어 있음.
  • 기능 플래그 k8s_proxy_pat는 GitLab 16.5에서 제거됨.

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

  1. 왼쪽 사이드바에서 아바타를 선택합니다.
  2. Edit profile을 선택한 다음 Applications을 선택합니다.
  3. Authorized applications 섹션을 확인합니다.

GitLab OAuth 2 애플리케이션은 스코프를 지원하며, 이를 통해 애플리케이션이 다양한 작업을 수행할 수 있도록 허용합니다.
사용 가능한 모든 스코프에 대한 표는 다음과 같습니다.

Scope Description
api 모든 그룹 및 프로젝트, 컨테이너 레지스트리, 의존성 프록시 및 패키지 레지스트리를 포함한 API에 대한 완전한 읽기/쓰기를 허용합니다.
read_user 사용자 인증된 프로필에 대한 읽기 전용 액세스를 /user API 엔드포인트를 통해 허용합니다. 여기에는 사용자 이름, 공개 이메일 및 전체 이름이 포함됩니다. 또한 /users 아래의 읽기 전용 API 엔드포인트에 대한 액세스를 허용합니다.
read_api 모든 그룹 및 프로젝트, 컨테이너 레지스트리 및 패키지 레지스트리를 포함한 API에 대한 읽기 액세스를 허용합니다.
read_repository Git-over-HTTP 또는 Repository Files API를 사용하여 개인 프로젝트의 리포지토리에 대한 읽기 전용 액세스를 허용합니다.
write_repository Git-over-HTTP를 사용하여 개인 프로젝트의 리포지토리에 대한 읽기-쓰기 액세스를 허용합니다 (API 사용하지 않음).
read_registry 개인 프로젝트에서 컨테이너 레지스트리 이미지에 대한 읽기 전용 액세스를 허용합니다.
write_registry 개인 프로젝트에서 컨테이너 레지스트리 이미지에 대한 읽기-쓰기 액세스를 허용합니다.
sudo 관리자로 인증된 경우 시스템의 모든 사용자로서 API 작업을 수행할 수 있는 권한을 부여합니다.
openid OpenID Connect를 사용하여 GitLab에 인증할 수 있는 권한을 부여합니다. 또한 사용자 프로필 및 그룹 멤버십에 대한 읽기 전용 액세스를 제공합니다.
profile OpenID Connect를 사용하여 사용자 프로필 데이터에 대한 읽기 전용 액세스를 허용합니다.
email OpenID Connect를 사용하여 사용자의 기본 이메일 주소에 대한 읽기 전용 액세스를 허용합니다.
create_runner 러너를 생성할 수 있는 권한을 부여합니다.
manage_runner 러너를 관리할 수 있는 권한을 부여합니다.
k8s_proxy Kubernetes 에이전트를 사용하여 Kubernetes API 호출을 수행할 수 있는 권한을 부여합니다.

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

액세스 토큰 만료

  • expires_in에 대한 데이터베이스 검증은 GitLab 15.10에서 도입됨. GitLab 인스턴스에 expires_in이 설정되지 않은 OAuth 액세스 토큰이 남아 있는 경우 15.10 또는 이후로 업그레이드할 때 데이터베이스 마이그레이션에서 오류가 발생합니다. 해결 방법 지침은 GitLab 15.10.0 업그레이드 문서를 참조하세요.

경고:
만료되는 액세스 토큰에서 선택 해제할 수 있는 기능은 GitLab 15.0에서 제거됨. 모든 기존 통합은 액세스 토큰 새로 고침을 지원하도록 업데이트해야 합니다.

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

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

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

해싱된 OAuth 애플리케이션 비밀


셀프 관리 GitLab에서는 기본적으로 이 기능이 제공됩니다. 이 기능을 숨기려면 관리자가 기능 플래그를 비활성화할 수 있습니다 이름은 hash_oauth_secrets.
GitLab.com에서는 이 기능이 제공됩니다.

기본적으로 GitLab은 OAuth 애플리케이션 비밀을 해시 형식으로 데이터베이스에 저장합니다. 이 비밀은 사용자가 OAuth 애플리케이션을 생성한 직후에만 사용할 수 있습니다.
이전 버전의 GitLab에서는 애플리케이션 비밀이 평문으로 데이터베이스에 저장되었습니다.

GitLab에서 OAuth 2를 사용하는 기타 방법

할 수 있습니다:

  • Applications API를 사용하여 OAuth 2 애플리케이션을 생성하고 관리합니다.
  • 사용자가 타사 OAuth 2 제공자를 사용하여 GitLab에 로그인할 수 있도록 합니다.
    자세한 내용은 OmniAuth 문서를 참조하세요.
  • OAuth 2를 사용하여 GitLab Importer로 리포지토리에 대한 액세스를 제공하며,
    사용자 자격 증명을 GitLab.com 계정과 공유하지 않습니다.