엔터프라이즈 로그인 작동 방식 사전 조건 1단계: 자격 증명 공급자에서 OIDC 애플리케이션 생성 2단계: IAM Identity Center에서 신뢰할 수 있는 토큰 발급자 생성 3단계: Amazon Quick 관리 콘솔에서 확장 액세스 구성 4단계: 데스크톱 애플리케이션 다운로드 및 배포 문제 해결

엔터프라이즈 배포를 위한 Amazon Quick on Desktop 설정

적용 대상: 엔터프라이즈 에디션 및 스탠다드 에디션

대상: 시스템 관리자

엔터프라이즈 배포에 Amazon Quick on Desktop을 사용하려면 관리자가 조직의 사용자가 회사 자격 증명으로 로그인할 수 있도록 엔터프라이즈 SSO(Single Sign-On)를 구성해야 합니다. 이 설정은 조직의 OpenID Connect(OIDC) 호환 ID 제공업체(IdP)를 Amazon Quick에 연결합니다.

참고

Free 또는 Plus 계정을 사용하는 경우이 섹션은 적용되지 않습니다. 계속해서 시작하기로 이동하세요.

설정에는 다음 단계가 순서대로 포함됩니다.

IdP에서 OIDC 애플리케이션을 생성합니다.
IAM Identity Center에서 신뢰할 수 있는 토큰 발급자(TTI)를 생성합니다(인증에 IAM Identity Center를 사용하는 계정에만 필요).
Amazon Quick 관리 콘솔에서 확장 액세스를 구성합니다.
데스크톱 애플리케이션을 사용자에게 배포합니다.

이 가이드에서는 Microsoft Entra ID, Okta 및 Ping Identity(PingFederate 및 PingOne)에 대한 IdP별 지침을 제공합니다. 아래에서 특정 자격 증명 공급자에 대한 지침을 참조하세요.

엔터프라이즈 로그인 작동 방식

Amazon Quick 데스크톱 애플리케이션은 OIDC 프로토콜을 사용하여 사용자를 인증합니다. 사용자가 엔터프라이즈 로그인을 선택하면 애플리케이션이 브라우저 창을 열고 IdP의 권한 부여 엔드포인트로 리디렉션합니다. 그런 다음 애플리케이션은 생성된 권한 부여 코드를 코드 교환용 증명 키(PKCE)를 사용하여 토큰으로 교환합니다.

Amazon Quick은 토큰을 검증하고 사용자를 계정의 자격 증명에 매핑합니다. IAM Identity Center를 사용하는 계정의 경우 TTI는 OIDC 토큰의 email 클레임을 자격 증명 스토어의 emails.value 속성에 매핑합니다. IAM 페더레이션을 사용하는 계정의 경우 Amazon Quick은 이메일로 사용자를 직접 매핑합니다. 두 경우 모두 IdP의 이메일 주소가 Amazon Quick에 있는 사용자의 이메일 주소와 정확히 일치해야 합니다.

사전 조건

시작하기 전에 다음이 있는지 확인합니다.

인증에 IAM Identity Center 또는 IAM 페더레이션을 사용하는 활성 Amazon Quick 구독이 있는 AWS 계정입니다. Amazon Quick 계정의 홈 리전(자격 증명 리전)은 미국 동부(버지니아 북부)(us-east-1)여야 합니다.
Amazon Quick 계정에 대한 관리자 액세스 권한.
OIDC 애플리케이션 등록을 생성할 수 있는 권한이 있는 IdP에 액세스합니다.

중요

Amazon Quick 계정의 홈 리전(자격 증명 리전)은 미국 동부(버지니아 북부)(us-east-1)여야 합니다. 데스크톱 애플리케이션에 대한 모든 추론도이 리전을 사용합니다. 웹의 Amazon Quick은 다른 리전에서 사용할 수 있지만 데스크톱 애플리케이션은 인증 및 추론을 위해 us-east-1에 연결됩니다.

1단계: 자격 증명 공급자에서 OIDC 애플리케이션 생성

IdP에 퍼블릭 OIDC 클라이언트 애플리케이션을 등록합니다. Amazon Quick 데스크톱 애플리케이션은이 클라이언트를 사용하여 PKCE를 통한 권한 부여 코드 흐름을 통해 사용자를 인증합니다. 클라이언트 보안 암호는 필요하지 않습니다.

데스크톱 애플리케이션에서는 수명이 긴 세션을 유지하려면 새로 고침 토큰이 필요합니다. 새로 고침 토큰 구성 방법은 IdP에 따라 다릅니다.

Microsoft Entra ID - offline_access 범위를 부여해야 합니다. 이 권한이 없으면 사용자는 자주 재인증해야 합니다.
Okta - 애플리케이션에서 새로 고침 토큰 권한 부여 유형을 활성화하고 offline_access 범위를 부여해야 합니다.
Ping Identity - 새로 고침 토큰 권한 부여 유형을 활성화하고 offline_access 범위를 부여해야 합니다. PingFederate의 경우 OIDC 정책에서 새로 고침 시 ID 토큰 반환 권한 부여 설정도 활성화해야 합니다.

자격 증명 공급자의 지침을 선택합니다.

Microsoft Entra ID

자세한 지침은 Microsoft Entra 설명서의 애플리케이션 등록을 참조하세요.

Entra ID 앱 등록을 생성하려면

Azure 포털에서 Microsoft Entra ID → 앱 등록 → 새 등록으로 이동합니다.

다음 설정을 구성합니다.

설정	값
이름	`Amazon Quick Desktop`
지원되는 계정 유형	이 조직 디렉터리의 계정만(단일 테넌트)
URI 플랫폼 리디렉션	퍼블릭 클라이언트/네이티브(모바일 및 데스크톱)
리디렉션 URI	`http://localhost:18080`

등록을 선택합니다.
개요 페이지에서 애플리케이션(클라이언트) ID와 디렉터리(테넌트) ID를 기록해 둡니다. 이후 단계에서는 이러한 값이 필요합니다.

퍼블릭 클라이언트 등록입니다. PKCE는 퍼블릭 클라이언트의 Entra ID에 의해 자동으로 적용됩니다.

API 권한을 구성하려면

앱 등록에서 API 권한 → 권한 추가 → Microsoft 그래프 → 위임된 권한으로 이동합니다.
openid, , email, 권한을 추가합니다profileoffline_access.
권한 추가를 선택합니다.
조직에 필요한 경우 [조직]에 대한 관리자 동의 부여를 선택합니다.

인증 설정을 구성하려면

앱 등록에서 인증으로 이동합니다.
고급 설정에서 퍼블릭 클라이언트 흐름 허용을 예로 설정합니다.
http://localhost:18080가 모바일 및 데스크톱 애플리케이션에 나열되어 있는지 확인합니다.
저장을 선택합니다.

OIDC 엔드포인트는 다음 형식을 사용합니다. 를 디렉터리(테넌트) ID<TENANT_ID>로 바꿉니다.

Field	값
발급자 URL	`https://login.microsoftonline.com/<TENANT_ID>/v2.0`
권한 부여 엔드포인트	`https://login.microsoftonline.com/<TENANT_ID>/oauth2/v2.0/authorize`
Token 엔드포인트	`https://login.microsoftonline.com/<TENANT_ID>/oauth2/v2.0/token`
JWKS URI	`https://login.microsoftonline.com/<TENANT_ID>/discovery/v2.0/keys`

Okta

자세한 지침은 Okta 설명서의 OpenID Connect 앱 통합 생성을 참조하세요.

Okta OIDC 네이티브 애플리케이션을 생성하려면

Okta 관리 콘솔에서 애플리케이션 → 애플리케이션 → 앱 통합 생성으로 이동합니다.
로그인 방법으로 OIDC - OpenID Connect를 선택합니다.
애플리케이션 유형으로 네이티브 애플리케이션을 선택한 후 다음을 선택합니다.

다음 설정을 구성합니다.

설정	값
앱 통합 이름	`Amazon Quick Desktop`
권한 부여 유형	권한 부여 코드 및 새로 고침 토큰
로그인 리디렉션 URIs	`http://localhost:18080`
Assignments	적절한 사용자 또는 그룹에 할당

저장을 선택합니다.
일반 탭에서 클라이언트 ID를 기록해 둡니다.

PKCE(S256)는 Okta에서 네이티브 애플리케이션에 자동으로 적용됩니다.

범위를 구성하려면

Okta 관리 콘솔에서 보안 → API → 권한 부여 서버로 이동하여 권한 부여 서버(예: 기본값)를 선택합니다.
범위 탭에서 , openid, email, 범위가 활성화되어 있는지 확인합니다profileoffline_access.
액세스 정책 탭에서이 애플리케이션에 할당된 정책이 Authorization Code 및 Refresh Token 권한 부여 유형을 허용하는지 확인합니다.

인증 설정을 확인하려면

앱 통합에서 일반 탭으로 이동합니다.
일반 설정에서 애플리케이션 유형이 네이티브이고 클라이언트 인증이 없음(퍼블릭 클라이언트)이며 PKCE가 필요한지 확인합니다.
로그인에서 http://localhost:18080가 리디렉션 URI로 나열되어 있는지 확인합니다.
변경한 경우 저장을 선택합니다.

OIDC 엔드포인트는 다음 형식을 사용합니다. 를 Okta 도메인(예: your-org.okta.com)<OKTA_DOMAIN>으로 바꿉니다.

Field	값
발급자 URL	`https://<OKTA_DOMAIN>/oauth2/default`
권한 부여 엔드포인트	`https://<OKTA_DOMAIN>/oauth2/default/v1/authorize`
Token 엔드포인트	`https://<OKTA_DOMAIN>/oauth2/default/v1/token`
JWKS URI	`https://<OKTA_DOMAIN>/oauth2/default/v1/keys`

Ping Identity

Ping Identity 제품의 지침을 선택합니다.

PingFederate

자세한 지침은 Ping Identity 설명서의 PingFederate에서 OIDC 애플리케이션 설정을 참조하세요.

PingFederate OIDC 클라이언트를 생성하려면

PingFederate 관리 콘솔에서 애플리케이션 → OAuth → 클라이언트로 이동하여 클라이언트 추가를 선택합니다.
클라이언트 ID 필드에이 클라이언트의 고유 식별자를 입력합니다.
이름 필드에 Amazon Quick Desktop을 입력합니다.
클라이언트 인증에서 없음을 선택합니다.
리디렉션 URI 섹션에서 http://localhost:18080를 입력하고 추가를 선택합니다.
허용된 권한 부여 유형 목록에서 권한 부여 코드 및 새로 고침 토큰을 선택합니다.
코드 교환에 증명 키 필요(PKCE) 확인란을 선택합니다.
공통 범위에서 , openid, email, profile를 부여합니다offline_access.
저장을 선택합니다.
클라이언트 ID를 기록해 둡니다. 이후 단계에서이 값이 필요합니다.

OIDC 정책을 구성하려면

PingFederate 관리 콘솔에서 애플리케이션 → OAuth → OpenID Connect 정책 관리로 이동합니다.
이 클라이언트와 연결된 OIDC 정책을 선택하거나 정책 추가를 선택하여 정책을 생성합니다.
새로 고침 권한 부여 시 ID 토큰 반환 확인란을 선택합니다. 이렇게 하면 데스크톱 애플리케이션이 세션을 새로 고칠 때 현재 클레임이 포함된 새 ID 토큰을 수신할 수 있습니다.
속성 계약에서 email 클레임이 포함되고 인증 소스의 해당 사용자 속성에 매핑되었는지 확인합니다. email 클레임은 초기 인증 및 새로 고침 토큰 권한 부여 중에 발급된 토큰에 있어야 합니다.
저장을 선택합니다.

OIDC 엔드포인트는 다음 형식을 사용합니다. <PINGFEDERATE_HOST>를 PingFederate 서버 호스트 이름으로 바꿉니다.

Field	값
발급자 URL	`https://<PINGFEDERATE_HOST>`
권한 부여 엔드포인트	`https://<PINGFEDERATE_HOST>/as/authorization.oauth2`
Token 엔드포인트	`https://<PINGFEDERATE_HOST>/as/token.oauth2`
JWKS URI	`https://<PINGFEDERATE_HOST>/pf/JWKS`

PingOne

자세한 지침은 Ping Identity 설명서의 Editing an application – Native를 참조하세요.

PingOne OIDC 네이티브 애플리케이션을 생성하려면

PingOne 관리자 콘솔에서 애플리케이션 → 애플리케이션으로 이동하여 + 아이콘을 선택합니다.
애플리케이션 이름으로 Amazon Quick Desktop를 입력합니다.
애플리케이션 유형 섹션에서 네이티브를 선택한 다음 저장을 선택합니다.

구성 탭에서 편집을 선택하고 다음 설정을 구성합니다.

설정	값
응답 유형	코드
권한 부여 유형	권한 부여 코드 및 새로 고침 토큰
PKCE 적용	S256
리디렉션 URI	`http://localhost:18080`
토큰 엔드포인트 인증 방법	없음

저장을 선택합니다.
리소스 탭에서 , openid, email, 범위를 추가합니다profileoffline_access.
속성 매핑 탭에서 email 속성이 사용자의 이메일 주소에 매핑되었는지 확인합니다.
애플리케이션을 활성화됨으로 전환합니다.
구성 탭의 클라이언트 ID와 환경 ID를 기록해 둡니다.

참고

PingOne 도메인은 리전에 따라 다릅니다. 아래 예제에서는를 사용합니다.com. 도메인을 환경의 도메인으로 바꿉니다(예: , .ca .eu또는 .asia).

OIDC 엔드포인트는 다음 형식을 사용합니다. 를 PingOne 환경 ID<ENV_ID>로 바꿉니다.

Field	값
발급자 URL	`https://auth.pingone.com/<ENV_ID>/as`
권한 부여 엔드포인트	`https://auth.pingone.com/<ENV_ID>/as/authorize`
Token 엔드포인트	`https://auth.pingone.com/<ENV_ID>/as/token`
JWKS URI	`https://auth.pingone.com/<ENV_ID>/as/jwks`

2단계: IAM Identity Center에서 신뢰할 수 있는 토큰 발급자 생성

참고

이 단계는 Amazon Quick 계정이 인증에 Identity Center를 사용하는 AWS Identity and Access Management 경우에만 필요합니다. 계정에서 IAM 페더레이션을 사용하는 경우이 단계를 건너뛰고 3단계로 진행합니다.

TTI는 IAM Identity Center에 IdP의 토큰을 신뢰하도록 지시하고 이를 IAM Identity Center 사용자에게 매핑하는 방법을 지시합니다. Identity Center 콘솔 또는 AWS CLI를 AWS Identity and Access Management 사용하여 TTI를 생성할 수 있습니다.

자세한 내용은 AWS Identity and Access Management Identity Center 사용 설명서의 신뢰할 수 있는 토큰 발급자 설정을 참조하세요.

IAM Identity Center 콘솔에서 TTI를 생성하려면

AWS Identity and Access Management Identity Center 콘솔을 엽니다.
설정을 선택합니다.
설정 페이지에서 인증 탭을 선택합니다.
신뢰할 수 있는 토큰 발급자에서 신뢰할 수 있는 토큰 발급자 선택을 선택합니다.

신뢰할 수 있는 토큰을 발급하도록 외부 IdP 설정 페이지의 신뢰할 수 있는 토큰 발급자 세부 정보에서 다음을 구성합니다.

Field	값
발급자 URL	1단계의 OIDC 발급자 URL(아래 표 참조)
신뢰할 수 있는 토큰 발급자 이름	`AmazonQuickDesktop`

맵 속성에서 IAM Identity Center가 사용자를 조회하는 데 사용하는 속성 매핑을 구성합니다.

Field	값
자격 증명 공급자 속성	사용자를 식별하는 IdP 토큰의 클레임(예: `email`)
IAM Identity Center 속성	IAM Identity Center ID 스토어의 해당 속성(예: `emails.value`)

중요

자격 증명 공급자 속성은 IdP가 토큰에 포함하는 클레임과 일치해야 하며, IAM Identity Center 속성은 자격 증명 스토어의 사용자를 고유하게 식별해야 합니다. 가장 일반적인 매핑은 email → emails.value이지만 조직에서 sub 또는 사용자 지정 클레임과 같은 다른 속성을 사용할 수 있습니다. 토큰 클레임의 값은 IAM Identity Center의 해당 속성 값과 정확히 일치해야 합니다.

신뢰할 수 있는 토큰 발급자 생성을 선택합니다.
신뢰할 수 있는 토큰 발급자 ARN을 기록해 둡니다. 이 정보는 다음 단계에서 필요합니다.

또는 AWS CLI를 사용하여 TTI를 생성하려면 다음 명령을 실행합니다. <IDC_INSTANCE_ARN>를 IAM Identity Center 인스턴스 Amazon 리소스 이름(ARN)으로 바꾸고를 1단계의 발급자 URL<ISSUER_URL>로 바꿉니다.


aws sso-admin create-trusted-token-issuer \
  --instance-arn <IDC_INSTANCE_ARN> \
  --name "AmazonQuickDesktop" \
  --trusted-token-issuer-type OIDC_JWT \
  --trusted-token-issuer-configuration '{
    "OidcJwtConfiguration": {
      "IssuerUrl": "<ISSUER_URL>",
      "ClaimAttributePath": "email",
      "IdentityStoreAttributePath": "emails.value",
      "JwksRetrievalOption": "OPEN_ID_DISCOVERY"
    }
  }'

출력TrustedTokenIssuerArn의를 기록해 둡니다. 이 정보는 다음 단계에서 필요합니다.

다음 표에는 각 자격 증명 공급자의 발급자 URL이 나열되어 있습니다.

ID 공급자	발급자 URL
Microsoft Entra ID	`https://login.microsoftonline.com/<TENANT_ID>/v2.0`
Okta	`https://<OKTA_DOMAIN>/oauth2/default`
PingFederate	`https://<PINGFEDERATE_HOST>`
PingOne	`https://auth.pingone.com/<ENV_ID>/as`

3단계: Amazon Quick 관리 콘솔에서 확장 액세스 구성

확장 액세스를 추가하려면

Amazon Quick 관리 콘솔에 로그인합니다.
권한에서 확장 액세스를 선택합니다.
확장 액세스 추가를 선택합니다.

(선택 사항) 계정이 IAM Identity Center를 사용하는 경우 신뢰할 수 있는 토큰 발급자 설정 단계가 나타납니다. 다음을 입력합니다.

Field	값
신뢰할 수 있는 토큰 발급자 ARN	2단계`TrustedTokenIssuerArn`의
aud 클레임	1단계의 클라이언트 ID

이 단계는 IAM 페더레이션을 사용하는 계정에는 표시되지 않습니다.

빠른 확장을 위한 데스크톱 애플리케이션을 선택하고 다음을 선택합니다.

Amazon Quick 확장 세부 정보를 입력합니다.

Field	값
이름	이 확장 액세스의 이름
설명	(선택 사항) 설명
발급자 URL	1단계의 OIDC 발급자 URL
권한 부여 엔드포인트	1단계의 OIDC 권한 부여 엔드포인트 URL
토큰 엔드포인트	1단계의 OIDC 토큰 엔드포인트 URL
JWKS URI	1단계의 JSON 웹 키 세트 URI
클라이언트 ID입니다	1단계의 OIDC 클라이언트 식별자

추가를 선택합니다.

중요
추가를 선택하기 전에 모든 값이 올바른지 확인합니다. 생성 후에는 확장 액세스 구성을 편집할 수 없습니다. 값이 올바르지 않은 경우 확장 액세스를 삭제하고 새 확장 액세스를 생성해야 합니다.

확장을 생성하려면

Amazon Quick 콘솔의 왼쪽 탐색 창에서 앱 및 데이터 연결에서 확장을 선택합니다.
확장 추가를 선택합니다.
이전에 생성한 빠른 확장 액세스를 위한 데스크톱 애플리케이션을 선택합니다. 다음을 선택합니다.
생성(Create)을 선택합니다.

4단계: 데스크톱 애플리케이션 다운로드 및 배포

엔터프라이즈 로그인을 구성한 후 데스크톱 애플리케이션을 직접 다운로드하고 설치하여 설정을 확인합니다. 로그인 화면에서 엔터프라이즈 로그인을 선택하고 회사 자격 증명으로 인증하여 구성이 작동하는지 확인합니다. 다운로드 및 설치 단계는 섹션을 참조하세요시작하기.

로그인에 실패하면 1단계의 OIDC 엔드포인트와 비교하여 3단계에서 입력한 값을 확인합니다. 값이 올바르지 않은 경우 권한 → 확장 액세스에서 확장 액세스를 삭제하고 올바른 값으로 3단계를 반복합니다.

설정을 확인한 후 다운로드, 설치 및 로그인 지침을 시작하기 위해 사용자를 로 안내합니다.

문제 해결

redirect_mismatch 오류: IdP의 리디렉션 URI가 정확하고 퍼블릭 클라이언트 또는 네이티브 플랫폼으로 구성되어 http://localhost:18080 있는지 확인합니다.
로그인 후 사용자를 찾을 수 없음: IdP 토큰의 이메일은 IAM Identity Center에 있는 사용자의 이메일과 정확히 일치해야 합니다. 사용자가 프로비저닝되었고 두 시스템에서 이메일 주소가 동일한지 확인합니다.
토큰 검증 실패: TTI의 발급자 URL이 IdP의 OIDC 구성의 발급자 URL과 정확히 일치하는지 확인합니다.
동의 또는 권한 오류(Microsoft Entra ID): Azure 포털에서 필요한 API 권한에 대한 관리자 동의를 부여합니다. 앱 등록의 API 권한 페이지로 이동하여 [조직]에 대한 관리자 동의 부여를 선택합니다.
세션이 자주 만료됨: IdP가 새로 고침 토큰을 발급하도록 구성되어 있는지 확인합니다. Microsoft Entra ID의 경우 offline_access 범위가 필요합니다. Okta의 경우 새로 고침 토큰 권한 부여 유형을 활성화하고 offline_access 범위를 부여해야 합니다. Ping Identity의 경우 새로 고침 토큰 권한 부여 유형을 활성화하고 offline_access 범위를 부여해야 합니다. PingFederate의 경우 OIDC 정책에서 새로 고침 시 반환 ID 토큰 권한 부여가 선택되어 있는지도 확인합니다.
invalid_scope 오류(Okta): 권한 부여 서버에서 offline_access가 활성화되어 있는지 확인합니다. 보안 → API → 권한 부여 서버 → 기본값 → 범위로 이동하여 범위가 있는지 확인합니다. 또한 애플리케이션의 액세스 정책이 새로 고침 토큰 권한 부여 유형을 허용하는지 확인합니다.
애플리케이션이 활성화되지 않음(PingOne): PingOne 로그인 페이지에 도달하지 않고 인증이 즉시 실패하는 경우 PingOne 관리자 콘솔에서 애플리케이션 토글이 활성화됨으로 설정되어 있는지 확인합니다.
새로 고침 후 이메일 클레임 누락(PingFederate): email 클레임이 OIDC 정책 속성 계약에 포함되어 있고 올바른 사용자 속성에 매핑되어 있는지 확인합니다. 매핑은 초기 인증 및 새로 고침 토큰 권한 부여 모두에 대한 email 클레임을 생성해야 합니다.

javascript가 브라우저에서 비활성화되거나 사용이 불가합니다.

AWS 설명서를 사용하려면 Javascript가 활성화되어야 합니다. 지침을 보려면 브라우저의 도움말 페이지를 참조하십시오.

문서 규칙

Amazon Quick on Desktop이란 무엇입니까?

시작하기