기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
엔터프라이즈 배포를 위한 Amazon Quick on Desktop 설정
| 적용 대상: 엔터프라이즈 에디션 및 스탠다드 에디션 |
| 대상: 시스템 관리자 |
엔터프라이즈 배포에 Amazon Quick on Desktop을 사용하려면 조직의 사용자가 회사 자격 증명으로 로그인할 수 있도록 관리자가 엔터프라이즈 SSO(Single Sign-On)를 구성해야 합니다. 이 설정은 조직의 OpenID Connect(OIDC) 호환 ID 제공업체(IdP)를 Amazon Quick에 연결합니다.
참고
Free 또는 Plus 계정을 사용하는 경우이 섹션은 적용되지 않습니다. 계속해서 시작하기로 이동하세요.
설정에는 다음 단계가 순서대로 포함됩니다.
-
IdP에서 OIDC 애플리케이션을 생성합니다.
-
Amazon Quick 관리 콘솔에서 확장 액세스를 구성합니다.
-
데스크톱 애플리케이션을 사용자에게 배포합니다.
이 가이드에서는 Microsoft Entra ID, Okta 및 Ping Identity(PingFederate 및 PingOne)에 대한 IdP별 지침을 제공합니다. 아래에서 특정 자격 증명 공급자에 대한 지침을 참조하세요.
엔터프라이즈 로그인 작동 방식
Amazon Quick 데스크톱 애플리케이션은 OIDC 프로토콜을 사용하여 사용자를 인증합니다. 사용자가 엔터프라이즈 로그인을 선택하면 애플리케이션이 브라우저 창을 열고 IdP의 권한 부여 엔드포인트로 리디렉션합니다. 그런 다음 애플리케이션은 PKCE(Proof Key for Code Exchange)를 사용하여 결과 권한 부여 코드를 토큰으로 교환합니다.
Amazon Quick은 토큰을 검증하고 사용자를 계정의 자격 증명에 매핑합니다. IdP의 이메일 주소는 Amazon Quick에 있는 사용자의 이메일 주소와 정확히 일치해야 합니다.
사전 조건
시작하기 전에 다음이 있는지 확인합니다.
-
활성 Amazon Quick 구독이 있는 AWS 계정입니다. Amazon Quick 계정의 홈 리전(자격 증명 리전)은 미국 동부(버지니아 북부)(us-east-1)여야 합니다. IAM Identity Center, IAM 페더레이션, 기본 Amazon Quick(사용자 이름/암호) 사용자를 포함한 모든 자격 증명 유형이 지원됩니다.
-
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:18080Assignments 적절한 사용자 또는 그룹에 할당 -
저장을 선택합니다.
-
일반 탭에서 클라이언트 ID를 기록해 둡니다.
PKCE(S256)는 Okta에서 기본 애플리케이션에 대해 자동으로 적용됩니다.
범위를 구성하려면
-
Okta 관리 콘솔에서 보안 → API → 권한 부여 서버로 이동하여 권한 부여 서버(예: 기본값)를 선택합니다.
-
범위 탭에서 ,
openid,email, 범위가 활성화되어 있는지 확인합니다profileoffline_access. -
액세스 정책 탭에서이 애플리케이션에 할당된 정책이
Authorization Code및Refresh Token권한 부여 유형을 허용하는지 확인합니다.
인증 설정을 확인하려면
-
앱 통합에서 일반 탭으로 이동합니다.
-
일반 설정에서 애플리케이션 유형이 네이티브이고 클라이언트 인증이 없음(퍼블릭 클라이언트)이며 PKCE가 필요한지 확인합니다.
-
LOGIN에서
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단계: Amazon Quick 관리 콘솔에서 확장 액세스 구성
확장 액세스를 추가하려면
-
Amazon Quick 관리 콘솔에 로그인합니다.
-
권한에서 확장 액세스를 선택합니다.
-
확장 액세스 추가를 선택합니다.
-
빠른 확장을 위한 데스크톱 애플리케이션을 선택하고 다음을 선택합니다.
-
Amazon Quick 확장 세부 정보를 입력합니다.
Field 값 이름 이 확장 액세스의 이름 설명 (선택 사항) 설명 발급자 URL 1단계의 OIDC 발급자 URL 권한 부여 엔드포인트 1단계의 OIDC 권한 부여 엔드포인트 URL 토큰 엔드포인트 1단계의 OIDC 토큰 엔드포인트 URL JWKS URI 1단계의 JSON 웹 키 세트 URI 클라이언트 ID입니다 1단계의 OIDC 클라이언트 식별자 -
추가를 선택합니다.
중요
추가를 선택하기 전에 모든 값이 올바른지 확인합니다. 생성 후에는 확장 액세스 구성을 편집할 수 없습니다. 값이 올바르지 않은 경우 확장 액세스를 삭제하고 새 확장 액세스를 생성해야 합니다.
확장을 생성하려면
-
Amazon Quick 콘솔의 왼쪽 탐색 창에서 앱 및 데이터 연결에서 확장을 선택합니다.
-
확장 추가를 선택합니다.
-
이전에 생성한 빠른 확장 액세스를 위한 데스크톱 애플리케이션을 선택합니다. 다음을 선택합니다.
-
생성(Create)을 선택합니다.
3단계: 데스크톱 애플리케이션 다운로드 및 배포
엔터프라이즈 로그인을 구성한 후 데스크톱 애플리케이션을 직접 다운로드하고 설치하여 설정을 확인합니다. 로그인 화면에서 엔터프라이즈 로그인을 선택하고 회사 자격 증명으로 인증하여 구성이 작동하는지 확인합니다. 다운로드 및 설치 단계는 섹션을 참조하세요시작하기.
로그인에 실패하면 1단계의 OIDC 엔드포인트와 비교하여 2단계에서 입력한 값을 확인합니다. 값이 올바르지 않은 경우 권한 → 확장 액세스에서 확장 액세스를 삭제하고 올바른 값으로 2단계를 반복합니다.
설정을 확인한 후 다운로드, 설치 및 로그인 지침을 시작하기 위해 사용자를 로 안내합니다.
문제 해결
redirect_mismatch오류-
IdP의 리디렉션 URI가 정확하고 퍼블릭 클라이언트 또는 네이티브 플랫폼으로 구성되어
http://localhost:18080있는지 확인합니다. - 로그인 후 사용자를 찾을 수 없음
-
IdP 토큰의 이메일은 Amazon Quick에 있는 사용자의 이메일과 정확히 일치해야 합니다. 사용자가 프로비저닝되었고 두 시스템에서 이메일 주소가 동일한지 확인합니다.
- 토큰 검증 실패
-
확장 액세스 구성의 발급자 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클레임을 생성해야 합니다.