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가 들어 있습니다.
    • Secret 필드에서 복사를 선택하여 접근 가능한 OAuth 2 클라이언트 비밀을 제공합니다.
    • GitLab 15.9 이상의 Secret 갱신 기능을 제공합니다. 이 기능을 사용하여이 애플리케이션의 새로운 비밀을 생성하고 복사할 수 있습니다. 비밀을 갱신하면 기존 애플리케이션이 인증서가 업데이트 될 때까지 작동하지 않습니다.

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

그룹을 위한 새로운 애플리케이션을 만들려면:

  1. 원하는 그룹으로 이동합니다.
  2. 왼쪽 사이드바에서 설정 > 애플리케이션을 선택합니다.
  3. 이름 및 리디렉션 URI를 입력합니다.
  4. 가능한 권한으로 OAuth 2 스코프를 선택합니다.
  5. 리디렉션 URI에서 사용자가 GitLab으로 승인한 후 보내지는 URL을 입력합니다.

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

    • 애플리케이션 ID에 OAuth 2 클라이언트 ID가 들어 있습니다.
    • Secret 필드에서 복사를 선택하여 접근 가능한 OAuth 2 클라이언트 비밀을 제공합니다.
    • GitLab 15.9 이상의 Secret 갱신 기능을 제공합니다. 이 기능을 사용하여이 애플리케이션의 새로운 비밀을 생성하고 복사할 수 있습니다. 비밀을 갱신하면 기존 애플리케이션이 인증서가 업데이트 될 때까지 작동하지 않습니다.

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

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

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

  1. 왼쪽 사이드바에서 아래쪽으로 이동하여 관리자를 선택합니다.
  2. 애플리케이션을 선택합니다.
  3. 새 애플리케이션을 선택합니다.

관리자 영역에서 애플리케이션을 생성할 때, 신뢰할 수 있는으로 표시합니다. 사용자 인증 단계가 이 애플리케이션에 대해 자동으로 건너뛰어집니다.

모든 인가 애플리케이션 보기

  • k8s_proxy는 GitLab 16.4에서 도입되었으며, 기본적으로 k8s_proxy_pat이란 이름의 플래그로 활성화됐습니다.
  • 관련 플래그 k8s_proxy_pat은 GitLab 16.5에서 제거되었습니다.

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

  1. 왼쪽 사이드바에서 아바타를 선택합니다.
  2. 프로필 편집을 선택한 다음 애플리케이션을 선택합니다.
  3. 인가된 애플리케이션 섹션을 확인합니다.

GitLab OAuth 2 애플리케이션은 애플리케이션이 다양한 작업을 수행하도록 허용하는 스코프를 지원합니다. 사용 가능한 모든 스코프에 대한 다음 테이블을 참조하십시오.

스코프 설명
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 호출을 수행할 수 있는 권한을 부여합니다.

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

액세스 토큰 만료

  • GitLab 15.10부터 도입된 데이터베이스 유효성 검사에서 expires_in를 사용합니다. GitLab 인스턴스에서 15.10 이상으로 업그레이드할 때 expires_in이 설정되지 않은 남은 OAuth 액세스 토큰이 있다면, 데이터베이스 마이그레이션이 오류를 발생시킵니다. 해결 방법은 GitLab 15.10.0 업그레이드 문서를 참조하세요.

경고: 액세스 토큰 만료 선택 사항이 GitLab 15.0에서 제거되었습니다. 모든 기존 통합을 업데이트하여 액세스 토큰 갱신을 지원해야 합니다.

액세스 토큰은 두 시간 후에 만료됩니다. 액세스 토큰을 사용하는 통합은 refresh_token 속성을 사용하여 새로운 액세스 토큰을 생성해야 합니다. 만료된 액세스 토큰을 갱신하는 방법에 대한 자세한 정보는 OAuth 2.0 토큰 문서를 참조하세요.

이 만료 설정은 GitLab 코드베이스에서 access_token_expires_in 구성을 사용하여 설정됩니다. 이 만료 설정은 구성할 수 없습니다.

응용 프로그램을 삭제하면 해당 응용 프로그램과 관련된 모든 부여 및 토큰도 삭제됩니다.

해시화된 OAuth 응용 프로그램 비밀

  • GitLab 15.4에서 도입되었습니다. 기본적으로 비활성화되어 있는 hash_oauth_secrets 라는 플래그가 있습니다.
  • GitLab 15.8에서 GitLab.com에서 활성화되었습니다.
  • GitLab 15.9에서 self-managed에서 활성화되었습니다.

플래그: 자체 호스팅 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를 사용하여 사용자 자격 증명을 공유하기 않고 저장소에 액세스할 수 있습니다.