GitLab을 OAuth 2.0 인증 식별 공급자로 구성하기

OAuth 2.0은 리소스 소유자를 대리하여 클라이언트 애플리케이션이 안전하게 위임된 서버 리소스에 액세스할 수 있게 합니다. OAuth 2.0은 인가 서버가 리소스 소유자 또는 최종 사용자의 승인으로 서드파티 클라이언트에 액세스 토큰을 발급할 수 있습니다.

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

이러한 방법은 권한 수준에 의해 다릅니다. 기본 콜백 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 14.1 및 이전 버전에서는 시크릿 필드에서.
      • GitLab 14.2 및 이후 버전에서는 시크릿 필드에서 복사를 선택함으로써 이슈.
    • GitLab 15.9 및 이후에서는 시크릿 재생성 기능을 제공합니다. 이 기능을 사용하여이 애플리케이션에 대해 새 시크릿을 생성하고 복사할 수 있습니다. 시크릿을 갱신하면 기존 응용 프로그램이 기능하지 않게되어 자격 증명을 업데이트할 때까지 기존 응용 프로그램이 기능하지 않게됩니다.

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

  • GitLab 13.11에서 도입되었습니다.

그룹에 대한 새 애플리케이션을 만들려면 다음을 수행하십시오:

  1. 원하는 그룹으로 이동합니다.
  2. 왼쪽 사이드 바에서 설정 > 응용 프로그램을 선택합니다.
  3. 이름 및 리디렉션 URI를 입력합니다.
  4. 인증된 응용 프로그램에서 정의된 OAuth 2 스코프를 선택합니다.
  5. 리디렉션 URI에 사용자가 GitLab로 승인한 후 전송되는 URL을 입력합니다.

  6. 응용 프로그램 저장을 선택합니다. GitLab은 다음을 제공합니다:

    • 응용 프로그램 ID에 OAuth 2 클라이언트 ID를 제공합니다.
    • OAuth 2 클라이언트 시크릿은 다음과 같이 액세스할 수 있습니다:
      • GitLab 14.1 및 이전 버전에서는 시크릿 필드에서.
      • GitLab 14.2 및 이후 버전에서는 시크릿 필드에서 복사를 선택함으로써 이슈.
    • GitLab 15.9 및 이후에서는 시크릿 재생성 기능을 제공합니다. 이 기능을 사용하여이 애플리케이션에 대해 새 시크릿을 생성하고 복사할 수 있습니다. 시크릿을 갱신하면 기존 응용 프로그램이 기능하지 않게되어 자격 증명을 업데이트할 때까지 기존 응용 프로그램이 기능하지 않게됩니다.

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

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

GitLab 인스턴스에 대한 응용 프로그램을 만들려면:

  1. 왼쪽 사이드바에서 가장 아래에 있는 관리 영역을 선택합니다.
  2. 응용 프로그램을 선택합니다.
  3. 새 응용 프로그램을 선택합니다.

관리 영역에서 응용 프로그램을 만들 때는 이를 신뢰된으로 표시합니다. 사용자 승인 단계는 자동으로이 응용 프로그램에 대해 생략됩니다.

모든 인가된 응용 프로그램 보기

  • k8s_proxy는 기본적으로 [이슈])https://gitlab.com/gitlab-org/gitlab/-/issues/422408)된 GitLab 16.4에서 사용 피처 플래그인 k8s_proxy_pat로 활성화됩니다.
  • 피처 플래그 k8s_proxy_pat는 GitLab 16.5에서 제거되었습니다.

GitLab 자격 증명으로 승인 한 모든 응용 프로그램을 보려면:

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

GitLab OAuth 2 응용 프로그램은 응용 프로그램이 다양한 작업을 수행할 수 있도록 하는 스코프를 지원합니다. 모든 사용 가능한 스코프에 대한 다음 표를 참조하십시오.

스코프 설명
api 그룹 및 프로젝트, 컨테이너 레지스트리, 의존성 프록시, 패키지 레지스트리를 포함한 API에 대한 완전한 읽기/쓰기 액세스를 부여합니다.
read_user 인증된 사용자의 프로필에 대한 읽기 전용 액세스를 부여합니다. 포함된 정보로는 사용자 이름, 공개 이메일, 전체 이름이 포함됩니다. 또한 /users 아래의 읽기 전용 API 엔드포인트에 대한 액세스를 부여합니다.
read_api 그룹 및 프로젝트, 컨테이너 레지스트리, 패키지 레지스트리를 포함한 API에 대한 읽기 액세스를 부여합니다.
read_repository Git-over-HTTP 또는 리포지터리 파일 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 러너를 생성할 수 있는 권한을 부여합니다.
k8s_proxy 쿠버네티스 에이전트를 사용하여 Kubernetes API 호출을 수행할 수 있는 권한을 부여합니다.

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

액세스 토큰 만료

  • GitLab 14.3에서 도입되었으며, 선택 사항으로 사용할 수 있습니다.
  • GitLab 15.0에서 액세스 토큰 만료 선택 사항을 제거.
  • GitLab 15.10에서 expires_in에 대한 데이터베이스 유효성 검사를 도입하였습니다. GitLab 인스턴스에서 15.10 이상으로 업그레이드할 때 expires_in이 설정되지 않은 OAuth 액세스 토큰이 남아있는 경우, 데이터베이스 이관 작업에서 오류가 발생합니다. 해결 방법은 GitLab 15.10.0 업그레이드 문서를 참조하십시오.
caution
액세스 토큰 만료 선택 사항은 GitLab 14.3에서 폐기되었으며 15.0에서 제거되었습니다. 기존 통합은 모두 액세스 토큰 갱신을 지원하도록 업데이트해야 합니다.

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

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

응용프로그램이 삭제되면 해당 응용프로그램과 관련된 모든 권한 및 토큰이 삭제됩니다.

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

  • GitLab 15.4에 동반되었으며, 기본적으로 비활성화된 hash_oauth_secrets라는 플래그로 제공됩니다.
  • GitLab 15.8에서 GitLab.com에서 활성화.
  • GitLab 15.9에서 Self-managed에서 활성화.

플래그: 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에 대한 사용자 자격 증명을 공유하지 않고 GitLab Importer를 사용하여 리포지터리에 액세스할 수 있습니다.