View a markdown version of this page

데스크톱에서 Amazon Quick에 대한 엔터프라이즈 로그인 문제 해결 - Amazon Quick

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

데스크톱에서 Amazon Quick에 대한 엔터프라이즈 로그인 문제 해결

 적용 대상: 엔터프라이즈 에디션 
   대상: 시스템 관리자 

사용하는 자격 증명 공급자에 관계없이 일반적인 엔터프라이즈 로그인 문제를 해결하려면 다음 지침을 따르십시오.

작은 정보

로그인 문제를 진단하는 데 도움이 되도록 로그인 화면에서 애플리케이션 로그를 내보낼 수 있습니다. 관리자 또는 AWS Support에 문의할 때 이러한 로그를 포함합니다.

참고

애플리케이션이 로그인 페이지에 도달하거나 인증을 완료하거나 콘텐츠를 로드할 수 없는 경우 네트워크와 관련된 문제일 수 있습니다. 제한된 환경에서 필요한 도메인이 허용 목록에 있고 방화벽 및 VPN 설정이 연결을 차단하지 않는지 확인합니다. 필수 도메인 목록은 섹션을 참조하세요네트워크 액세스 및 필수 도메인.

redirect_mismatch 오류

IdP의 리디렉션 URI가 정확하고 퍼블릭 클라이언트 또는 네이티브 플랫폼으로 구성되어 http://localhost:18080 있는지 확인합니다.

로그인 후 사용자를 찾을 수 없음

이 오류에는 두 가지 일반적인 원인이 있습니다.

  1. 이메일 클레임이 토큰에 반환되지 않습니다. Microsoft Entra ID의 경우 토큰 구성에서 ID 토큰에 email 선택적 클레임을 추가해야 합니다(1단계 참조). 또한 사용자의 Mail 속성을 Entra ID 프로필에 채워야 합니다. 사용자 보안 주체 이름(UPN)만으로는 충분하지 않습니다.

  2. Amazon Quick에 일치하는 사용자가 없습니다. 토큰의 이메일은 프로비저닝된 사용자의 이메일과 정확히 일치해야 합니다. IAM Identity Center 계정의 경우 Identity Center 일치 항목에서 사용자의 이메일을 확인합니다. 이메일 일치는 대/소문자를 구분합니다.

토큰 검증 실패

확장 액세스 구성의 발급자 URL이 IdP의 OIDC 구성의 발급자 URL과 정확히 일치하는지 확인합니다.

잘못된 발급자 오류(Microsoft Entra ID)

"잘못된 발급자: https://login.microsoftonline.com/TENANT_ID/v2.0"로 로그인에 실패하는 경우 확장 액세스 구성의 발급자 URL에 /v2.0 경로 접미사가 포함되어 있는지 확인합니다. Entra ID v2.0 엔드포인트는를 포함하는 iss 클레임과 함께 토큰을 발급합니다/v2.0. 접미사가 누락된 경우 확장 액세스를 삭제하고 올바른 발급자 URL로 다시 생성합니다.

이 계정에 대해 엔터프라이즈 로그인이 구성되지 않음

이 오류는 확장 액세스가 생성되었지만 확장 자체는 생성되지 않았음을 의미합니다. Amazon Quick 콘솔의 왼쪽 탐색 창에서 확장을 선택하고(찾으려면 보기를 선택해야 할 수 있음) 이전에 구성한 확장 액세스를 선택하여 확장을 생성합니다.

사용자 정보 요청 실패(HTTP 504)

이는 일시적인 백엔드 제한 시간입니다. 먼저 웹 브라우저를 통해 Amazon Quick 계정에 로그인한 다음 데스크톱 로그인을 다시 시도합니다. 오류가 지속되면 Amazon Quick Service 엔드포인트에 대한 네트워크 연결을 확인합니다. 필수 도메인 목록은 섹션을 참조하세요네트워크 액세스 및 필수 도메인.

동의 또는 권한 오류(Microsoft Entra ID)

Azure 포털에서 필요한 API 권한에 대한 관리자 동의를 부여합니다. 앱 등록의 API 권한 페이지로 이동하여 [조직]에 대한 관리자 동의 부여를 선택합니다.

세션이 자주 만료됨

IdP가 새로 고침 토큰을 발급하도록 구성되어 있는지 확인합니다. Microsoft Entra ID의 경우 offline_access 범위가 필요합니다. Google Workspace의 경우 권한 부여 요청에 access_type=offline를 포함합니다(빠르게 자동으로 처리됨). Okta의 경우 새로 고침 토큰 권한 부여 유형을 활성화하고 offline_access 범위를 부여해야 합니다. Ping Identity의 경우 새로 고침 토큰 권한 부여 유형을 활성화하고 offline_access 범위를 부여해야 합니다. PingFederate의 경우 OIDC 정책에서 새로 고침 시 반환 ID 토큰 권한 부여가 선택되어 있는지도 확인합니다.

invalid_scope 오류(Okta)

권한 부여 서버에서 offline_access가 활성화되어 있는지 확인합니다. 보안 → API → 권한 부여 서버 → 기본값 → 범위로 이동하여 범위가 있는지 확인합니다. 또한 애플리케이션의 액세스 정책이 새로 고침 토큰 권한 부여 유형을 허용하는지 확인합니다.

애플리케이션이 활성화되지 않음(PingOne)

PingOne 로그인 페이지에 도달하지 않고 인증이 즉시 실패하는 경우 PingOne 관리자 콘솔에서 애플리케이션 토글이 활성화됨으로 설정되어 있는지 확인합니다.

새로 고침 후 이메일 클레임 누락(PingFederate)

email 클레임이 OIDC 정책 속성 계약에 포함되어 있고 올바른 사용자 속성에 매핑되어 있는지 확인합니다. 매핑은 초기 인증 및 새로 고침 토큰 권한 부여 모두에 대한 email 클레임을 생성해야 합니다.