OAuth 클라이언트를 공유하는 방법

이 페이지에서는 조직 내의 다른 애플리케이션과 OAuth 클라이언트를 공유하는 방법을 설명합니다.

개요

프로젝트 간에 OAuth 클라이언트를 공유한다는 것은 각 애플리케이션에 대해 새 OAuth 클라이언트를 만드는 대신 여러 IAP(Identity-Aware Proxy) 보호 애플리케이션에 단일 커스텀 OAuth 클라이언트를 사용하는 것을 의미합니다. 이 접근 방식은 특히 애플리케이션이 많은 조직의 관리를 간소화합니다.

IAP를 구성할 때 다음 두 가지 OAuth 클라이언트 유형 중 하나를 사용할 수 있습니다.

  • Google 관리 OAuth 클라이언트: IAP는 기본적으로 이를 자동으로 사용합니다. 이 기본 제공 옵션은 수동 클라이언트 생성이 필요하지 않지만 두 가지 주요 제한사항이 있습니다.

    • 조직 내 사용자(내부 사용자)에게만 액세스 허용

    • 조직의 브랜딩 대신 동의 화면에 Google Cloud 브랜딩을 표시합니다.

  • 커스텀 OAuth 클라이언트: 직접 만들고 관리합니다. 이 옵션은 다음을 수행합니다.

    • 여러 애플리케이션에서 공유할 수 있음

    • 동의 화면에서 브랜딩 맞춤설정 허용

    • 외부 사용자(조직 외부)의 액세스 지원

커스텀 OAuth 클라이언트를 만들면 단일 애플리케이션에서 사용하거나 여러 애플리케이션에서 공유할 수 있습니다. 커스텀 OAuth 클라이언트를 공유하면 다음과 같은 몇 가지 이점이 있습니다.

  • 여러 클라이언트를 관리하는 데 드는 관리 오버헤드 감소

  • 사용자 인증 정보 페이지에 액세스할 수 없는 팀 구성원을 위해 IAP 사용 설정을 간소화합니다.

  • IAP로 보호되는 애플리케이션에 대한 프로그래매틱(비브라우저) 액세스를 지원합니다.

OAuth 클라이언트 만들기에 대한 자세한 내용은 IAP용 OAuth 클라이언트 만들기를 참조하세요. Google 관리 OAuth 클라이언트에 대한 자세한 내용은 IAP를 사용 설정하도록 OAuth 구성 맞춤설정을 참조하세요.

시작하기 전에

OAuth 클라이언트 만들기의 단계를 완료하여 새 OAuth 클라이언트를 만들거나 기존 OAuth 클라이언트를 사용합니다.

프로그래매틱 액세스

프로그래매틱 액세스를 위해 OAuth 클라이언트를 구성하여 브라우저가 아닌 애플리케이션이 IAP로 보호되는 리소스로 인증할 수 있도록 합니다. 이를 통해 스크립트, 자동화된 작업, 백엔드 서비스가 대화형 사용자 로그인 없이 보호된 애플리케이션에 안전하게 액세스할 수 있습니다.

이러한 인증 설정은 조직, 폴더, 프로젝트 등 리소스 계층 구조의 모든 수준에서 적용할 수 있습니다.

구현 단계는 프로그래매틱 인증 가이드 및 IAP 설정 관리 문서를 참조하세요.

gcloud

  1. OAuth 클라이언트 ID가 포함된 설정 파일을 준비합니다.

    cat << EOF > SETTINGS_FILENAME
      access_settings:
        oauth_settings:
          programmatic_clients: [clientId1, clientId2, ..]
    EOF
    
  2. gcloud iap settings set 명령어를 사용하여 설정을 적용합니다.

    gcloud iap settings set SETTINGS_FILENAME \
      [--organization=ORGANIZATION | --folder=FOLDER | --project=PROJECT] \
      [--resource-type=RESOURCE_TYPE] \
      [--service=SERVICE] \
      [--version=VERSION]
    

    명령어 예시:

    # Organization level
    gcloud iap settings set SETTINGS_FILENAME --organization=ORGANIZATION
    
    # Folder level
    gcloud iap settings set SETTINGS_FILENAME --folder=FOLDER
    
    # Project level (web resources)
    gcloud iap settings set SETTINGS_FILENAME \
      --project=PROJECT \
      --resource-type=iap_web
    
    # App Engine service in a project
    gcloud iap settings set SETTINGS_FILENAME \
      --project=PROJECT \
      --resource-type=app-engine \
      --service=SERVICE
    

    각 항목의 의미는 다음과 같습니다.

    • SETTINGS_FILENAME: 준비한 YAML 파일입니다.

    • ORGANIZATION: 조직 ID

    • FOLDER: 폴더 ID

    • PROJECT: 프로젝트 ID

    • RESOURCE_TYPE: IAP 리소스 유형(app-engine, iap_web, compute, organization, folder)

    • SERVICE: 서비스 이름(compute 또는 app-engine 리소스 유형의 경우 선택사항)

    • VERSION: 버전 이름(compute에는 적용되지 않으며 app-engine에는 선택사항)

API

  1. 설정 JSON 파일을 준비합니다.

    cat << EOF > iap_settings.json
    {
      "access_settings": {
        "oauth_settings": {
          programmatic_clients: [clientId1, clientId2, ..]
        }
      }
    }
    EOF
    
  2. 리소스 이름을 가져옵니다.

    gcloud iap settings get \
      [--organization=ORGANIZATION | --folder=FOLDER | --project=PROJECT] \
      [--resource-type=RESOURCE_TYPE] \
      [--service=SERVICE] \
      [--version=VERSION]
    
  3. 리소스 이름을 사용하여 설정을 업데이트합니다.

    curl -X PATCH \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    -H "Accept: application/json" \
    -H "Content-Type: application/json" \
    -d @iap_settings.json \
    "https://iap.googleapis.com/v1/RESOURCE_NAME:iapSettings?updateMask=iapSettings.accessSettings.oauthSettings.programmaticClients"
    

    각 항목의 의미는 다음과 같습니다.

    • ORGANIZATION: 조직 ID

    • FOLDER: 폴더 ID

    • PROJECT: 프로젝트 ID

    • RESOURCE_TYPE: IAP 리소스 유형(app-engine, iap_web, compute, organization, folder)

    • SERVICE: 서비스 이름(compute 또는 app-engine 리소스 유형의 경우 선택사항)

    • VERSION: 버전 이름(compute에는 적용되지 않으며 app-engine에는 선택사항)

구성 후 구성한 OAuth 클라이언트 ID 중 하나를 사용하여 애플리케이션에 로그인합니다. 자세한 내용은 프로그래매틱 인증을 참조하세요.

브라우저 액세스

IAP가Google Cloud 콘솔을 통해 클라이언트 ID 및 보안 비밀을 사용하도록 설정하려면 다음 안내를 완료합니다.

위험

애플리케이션 간에 클라이언트를 공유하는 것은 편리하지만 위험이 있습니다. 이 섹션에서는 클라이언트를 공유할 때 발생할 수 있는 위험과 이를 완화하는 방법에 대해 설명합니다.

단일 장애점

여러 애플리케이션에 하나의 OAuth 클라이언트를 사용하면 단일 종속 항목이 생성됩니다. 클라이언트가 잘못 삭제되거나 수정되면 해당 클라이언트를 사용하는 모든 애플리케이션이 영향을 받습니다. 삭제된 OAuth 클라이언트는 30일 이내에 복원할 수 있습니다.

이러한 운영 위험을 효과적으로 관리하려면 다음을 수행해야 합니다.

이는 보안 위험이라기보다는 주로 운영 위험입니다. 적절한 액세스 제어 및 모니터링이 마련되어 있으면 공유 OAuth 클라이언트의 편의성과 관리 이점이 일반적으로 이러한 고려사항보다 더 큽니다.

클라이언트 보안 비밀번호 유출

클라이언트를 공유하려면 클라이언트 보안 비밀번호를 다른 사용자 및 스크립트와 공유해야 합니다. 이로 인해 클라이언트 보안 비밀번호 유출 위험이 높아집니다. IAP는 애플리케이션에서 생성된 토큰과 유출된 클라이언트 보안 비밀번호에서 생성된 토큰을 구분할 수 없습니다.

이러한 위험을 완화하려면 다음을 수행하세요.

  • 비밀번호와 같은 클라이언트 보안 비밀번호를 보호하고 일반 텍스트로 저장하지 않음

  • Secret Manager를 사용하여 안전한 사용자 인증 정보 관리 구현

  • Cloud 감사 로그으로 IAP 리소스에 대한 액세스 모니터링

  • 유출된 클라이언트 보안 비밀번호는 인증에만 영향을 미치며 리소스 액세스 승인에는 영향을 미치지 않습니다. 보안 비밀이 유출된 것으로 의심되면 즉시 재설정하세요.

IAP로 보호되는 리소스에 프로그래매틱 방식으로 액세스하려면 개별 사용자와 OAuth 클라이언트 보안 비밀번호를 공유하는 대신 서비스 계정 JWT 인증을 사용하는 것이 좋습니다. 이 접근 방식은 애플리케이션에 공유 OAuth 클라이언트의 이점을 유지하면서 더 나은 보안 격리를 제공합니다.

권한 범위 고려사항

OAuth 클라이언트를 공유할 때 모든 애플리케이션은 동일한 권한 범위를 사용합니다. IAP의 경우 openid 및 email만 필수 범위입니다. 이 고려사항 자체는 큰 위험이 아니지만 다음을 이해하는 것이 중요합니다.

  • OAuth는 IAP에서 인증(ID 확인)에만 사용됩니다. 승인(리소스 액세스)은 IAM 정책을 통해 별도로 처리됩니다.

  • 사용자 인증 정보가 유출되더라도 공격자가 보호된 리소스에 액세스하려면 적절한 IAM 권한이 필요합니다.

  • 클라이언트를 필요한 openid 및 email 범위로만 제한하면 잠재적인 보안 영향을 제한하는 데 도움이 됩니다.