View a markdown version of this page

엔터프라이즈 배포를 위한 Amazon Quick on Desktop 설정 - Amazon Quick
엔터프라이즈 로그인 작동 방식사전 조건1단계: 자격 증명 공급자에서 OIDC 애플리케이션 생성2단계: Amazon Quick 관리 콘솔에서 확장 액세스 구성3단계: 데스크톱 애플리케이션 다운로드 및 배포문제 해결

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

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

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

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

참고

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

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

  1. IdP에서 OIDC 애플리케이션을 생성합니다.

  2. Amazon Quick 관리 콘솔에서 확장 액세스를 구성합니다.

  3. 데스크톱 애플리케이션을 사용자에게 배포합니다.

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

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

Amazon Quick 데스크톱 애플리케이션은 OIDC 프로토콜을 사용하여 사용자를 인증합니다. 사용자가 SSO 계속을 선택하면 애플리케이션이 브라우저 창을 열고 IdP의 권한 부여 엔드포인트로 리디렉션합니다. 그런 다음 애플리케이션은 PKCE(Proof Key for Code Exchange)를 사용하여 결과 권한 부여 코드를 토큰으로 교환합니다.

Amazon Quick은 토큰을 검증하고 사용자를 계정의 자격 증명에 매핑합니다. IdP의 이메일 주소는 Amazon Quick에 있는 사용자의 이메일 주소와 정확히 일치해야 합니다.

사전 조건

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

  • 활성 Amazon Quick 구독이 있는AWS계정입니다. Amazon Quick 계정의 홈 리전(자격 증명 리전)은 지원되는에 있어야 합니다AWS 리전. 지원되는 리전 목록은 Amazon Quick AWS 리전 에 지원됨 섹션을 참조하세요. IAM Identity Center, IAM 페더레이션, 기본 Amazon Quick(사용자 이름/암호) 사용자를 포함한 모든 자격 증명 유형이 지원됩니다.

  • Amazon Quick 계정에 대한 관리자 액세스 권한.

  • OIDC 애플리케이션 등록을 생성할 수 있는 권한이 있는 IdP에 액세스합니다.

중요

Amazon Quick on Desktop은 전체 Amazon Quick 기능 세트를AWS 리전지원하는의 엔터프라이즈 계정에 사용할 수 있습니다. Amazon Quick 기능만 지원하는 리전에는 데스크톱이 포함되지 않습니다. 전체 목록은 Amazon Quick AWS 리전 에 지원됨 단원을 참조하십시오.

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

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

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

  • Microsoft Entra ID - offline_access 범위를 부여해야 합니다. 이 권한이 없으면 사용자는 자주 재인증해야 합니다.

  • Google Workspace - 권한 부여 요청에 access_type=offline 파라미터를 포함합니다. Google은 첫 번째 권한 부여 시 새로 고침 토큰을 발급합니다. 추가 범위 또는 권한 부여 유형 구성은 필요하지 않습니다.

  • Okta - 애플리케이션에서 새로 고침 토큰 권한 부여 유형을 활성화하고 offline_access 범위를 부여해야 합니다.

  • Ping Identity - 새로 고침 토큰 권한 부여 유형을 활성화하고 offline_access 범위를 부여해야 합니다. PingFederate의 경우 OIDC 정책에서 새로 고침 시 ID 토큰 반환 권한 부여 설정도 활성화해야 합니다.

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

Microsoft Entra ID

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

Entra ID 앱 등록을 생성하려면

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

  2. 다음 설정을 구성합니다.

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

  3. 등록을 선택합니다.

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

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

API 권한을 구성하려면

  1. 앱 등록에서 API 권한 → 권한 추가 → Microsoft 그래프 → 위임된 권한으로 이동합니다.

  2. openid, , email, 권한을 추가합니다profileoffline_access.

  3. 권한 추가를 선택합니다.

  4. 조직에 필요한 경우 [조직]에 대한 관리자 동의 부여를 선택합니다.

인증 설정을 구성하려면

  1. 앱 등록에서 인증으로 이동합니다.

  2. 고급 설정에서 퍼블릭 클라이언트 흐름 허용을 예로 설정합니다.

  3. http://localhost:18080가 모바일 및 데스크톱 애플리케이션에 나열되어 있는지 확인합니다.

  4. 저장을 선택합니다.

토큰 클레임을 구성하려면

  1. 앱 등록에서 토큰 구성으로 이동합니다.

  2. 선택적 클레임 추가를 선택합니다.

  3. 토큰 유형: ID를 선택합니다.

  4. email 클레임을 선택하고 추가를 선택합니다.

중요

이 단계는 필수입니다. email 선택적 클레임이 없으면 Microsoft Entra ID는 ID 토큰에 사용자의 이메일 주소를 포함하지 않으며 Amazon Quick은 토큰을 사용자에게 매핑할 수 없습니다. 또한 로그인하는 각 사용자는 Entra ID 프로필(연락처 정보 아래)에 메일 속성이 채워져 있어야 합니다. 사용자 보안 주체 이름(UPN)만으로는 충분하지 않습니다. 메일 속성에는 값이 포함되어야 합니다.

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

중요

발급자 URL에는 /v2.0 경로 접미사가 포함되어야 합니다. Entra ID 엔드포인트 패널에 표시된 "권한 URL"을 사용하지 마십시오. 그러면이 접미사가 생략됩니다. /v2.0 접미사가 누락된 경우 로그인 시 "잘못된 발급자" 오류와 함께 토큰 검증이 실패합니다.

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
작은 정보

JWKS URI는 Microsoft Entra ID 엔드포인트 패널에 표시되지 않습니다. 엔드포인트 패널에서 OpenID Connect 메타데이터 문서 URL을 열고 JSON 응답에서 jwks_uri 필드를 찾아 찾을 수 있습니다. 또는 이전 표에 표시된 형식을 사용하여 구성합니다.

Google Workspace

자세한 지침은 개발자용 Google 설명서의 모바일 및 데스크톱 앱용 OAuth 2.0을 참조하세요.

Google OAuth 클라이언트를 생성하려면

  1. Google Cloud Console에서 APIs 및 서비스 → 자격 증명 → 자격 증명 생성 → OAuth 클라이언트 ID로 이동합니다.

  2. 다음 설정을 구성합니다.

    설정 값
    애플리케이션 유형 데스크톱 앱
    이름 Amazon Quick Desktop

  3. 생성(Create)을 선택합니다.

  4. 클라이언트 ID와 클라이언트 보안 암호를 기록해 둡니다. 이후 단계에서는 이러한 값이 필요합니다.

OAuth 동의 화면을 구성하려면

  1. Google Cloud Console에서 Google Auth 플랫폼 → 브랜딩으로 이동합니다.

  2. 사용자 유형을 내부로 설정합니다. 이렇게 하면 Google Workspace 조직의 사용자로 로그인이 제한됩니다.

  3. 필요한 앱 정보를 입력하고 저장을 선택합니다.

범위를 구성하려면

  1. Google Cloud Console에서 Google Auth 플랫폼 → 데이터 액세스로 이동합니다.

  2. openid, , 범위를 추가합니다emailprofile.

  3. 저장을 선택합니다.

Google은 데스크톱 애플리케이션용 PKCE를 지원합니다. access_type=offline 파라미터가 권한 부여 요청에 포함되면 새로 고침 토큰이 자동으로 발급됩니다. 추가 구성은 필요하지 않습니다.

OIDC 엔드포인트는 다음과 같습니다.

Field 값
발급자 URL https://accounts.google.com
권한 부여 엔드포인트 https://accounts.google.com/o/oauth2/v2/auth
Token 엔드포인트 https://oauth2.googleapis.com/token?client_secret=<CLIENT_SECRET>
JWKS URI https://www.googleapis.com/oauth2/v3/certs
참고

토큰 교환이 성공하도록 토큰 엔드포인트에 클라이언트 암호를 client_secret 쿼리 파라미터로 추가합니다. 예: https://oauth2.googleapis.com/token?client_secret=<CLIENT_SECRET>. 를 OAuth 클라이언트에 대해 생성된 클라이언트 보안 암호<CLIENT_SECRET>로 바꿉니다.

Okta

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

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

  1. Okta 관리 콘솔에서 애플리케이션 → 애플리케이션 → 앱 통합 생성으로 이동합니다.

  2. 로그인 방법으로 OIDC - OpenID Connect를 선택합니다.

  3. 애플리케이션 유형으로 네이티브 애플리케이션을 선택한 후 다음을 선택합니다.

  4. 다음 설정을 구성합니다.

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

  5. 저장을 선택합니다.

  6. 일반 탭에서 클라이언트 ID를 기록해 둡니다.

PKCE(S256)는 Okta에서 기본 애플리케이션에 대해 자동으로 적용됩니다.

범위를 구성하려면

  1. Okta 관리 콘솔에서 보안 → API → 권한 부여 서버로 이동하여 권한 부여 서버(예: 기본값)를 선택합니다.

  2. 범위 탭에서 , openid, email, 범위가 활성화되어 있는지 확인합니다profileoffline_access.

  3. 액세스 정책 탭에서이 애플리케이션에 할당된 정책이 Authorization Code 및 Refresh Token 권한 부여 유형을 허용하는지 확인합니다.

인증 설정을 확인하려면

  1. 앱 통합에서 일반 탭으로 이동합니다.

  2. 일반 설정에서 애플리케이션 유형이 네이티브이고 클라이언트 인증이 없음(퍼블릭 클라이언트)이며 PKCE가 필요한지 확인합니다.

  3. LOGIN에서 http://localhost:18080가 리디렉션 URI로 나열되었는지 확인합니다.

  4. 변경한 경우 저장을 선택합니다.

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 클라이언트를 생성하려면

  1. PingFederate 관리 콘솔에서 애플리케이션 → OAuth → 클라이언트로 이동하여 클라이언트 추가를 선택합니다.

  2. 클라이언트 ID 필드에이 클라이언트의 고유 식별자를 입력합니다.

  3. 이름 필드에 Amazon Quick Desktop을 입력합니다.

  4. 클라이언트 인증에서 없음을 선택합니다.

  5. 리디렉션 URI 섹션에서를 http://localhost:18080 입력하고 추가를 선택합니다.

  6. 허용된 권한 부여 유형 목록에서 권한 부여 코드 및 새로 고침 토큰을 선택합니다.

  7. 코드 교환에 증명 키 필요(PKCE) 확인란을 선택합니다.

  8. 공통 범위에서 , openid, email,를 부여합니다profileoffline_access.

  9. 저장을 선택합니다.

  10. 클라이언트 ID를 기록해 둡니다. 이후 단계에서이 값이 필요합니다.

OIDC 정책을 구성하려면

  1. PingFederate 관리 콘솔에서 애플리케이션 → OAuth → OpenID Connect 정책 관리로 이동합니다.

  2. 이 클라이언트와 연결된 OIDC 정책을 선택하거나 정책 추가를 선택하여 정책을 생성합니다.

  3. 새로 고침 권한 부여 시 ID 토큰 반환 확인란을 선택합니다. 이렇게 하면 데스크톱 애플리케이션이 세션을 새로 고칠 때 현재 클레임이 포함된 새 ID 토큰을 수신할 수 있습니다.

  4. 속성 계약에서 email 클레임이 포함되고 인증 소스의 해당 사용자 속성에 매핑되었는지 확인합니다. email 클레임은 초기 인증 및 새로 고침 토큰 권한 부여 중에 발급된 토큰에 있어야 합니다.

  5. 저장을 선택합니다.

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 네이티브 애플리케이션을 생성하려면

  1. PingOne 관리자 콘솔에서 애플리케이션 → 애플리케이션으로 이동하여 + 아이콘을 선택합니다.

  2. 애플리케이션 이름으로 Amazon Quick Desktop를 입력합니다.

  3. 애플리케이션 유형 섹션에서 네이티브를 선택한 다음 저장을 선택합니다.

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

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

  5. 저장을 선택합니다.

  6. 리소스 탭에서 , openid, email, 범위를 추가합니다profileoffline_access.

  7. 속성 매핑 탭에서 email 속성이 사용자의 이메일 주소에 매핑되었는지 확인합니다.

  8. 애플리케이션을 활성화됨으로 전환합니다.

  9. 구성 탭의 클라이언트 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 관리 콘솔에서 확장 액세스 구성

확장 액세스를 추가하려면

  1. Amazon Quick 관리 콘솔에 로그인하고 계정 관리를 선택합니다.

  2. 왼쪽 탐색 창의 권한에서 확장 액세스를 선택합니다.

  3. 확장 액세스 추가를 선택합니다.

  4. 서비스 선택에서 Amazon Quick(빠른용 데스크톱 애플리케이션)을 선택하고 다음을 선택합니다.

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

    Field 값 설명
    이름 이 확장 액세스의 이름(예: QuickDesktop-access) 내부 참조 전용. 이 이름은 IdP에 구성되지 않았습니다. 영숫자 및 하이픈만 가능하며 공백은 없습니다.
    설명 (선택 사항)이 확장 액세스에 대한 설명 선택 사항. 참조용입니다.
    발급자 URL 1단계의 OIDC 발급자 URL Entra ID의 /v2.0 접미사를 포함해야 합니다.
    권한 부여 엔드포인트 1단계의 OIDC 권한 부여 엔드포인트 URL
    토큰 엔드포인트 1단계의 OIDC 토큰 엔드포인트 URL
    JWKS URI 1단계의 JSON 웹 키 세트 URI
    클라이언트 ID입니다 1단계의 OIDC 클라이언트 식별자

  6. 추가를 선택합니다.

    중요

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

확장을 생성하려면

  1. Amazon Quick Management 콘솔의 왼쪽 탐색 창에서 Quick을 선택한 다음 앱 및 데이터 연결에서 확장을 선택합니다.

  2. 확장 추가를 선택합니다.

  3. 이전에 생성한 빠른 확장 액세스를 위한 데스크톱 애플리케이션을 선택합니다. 다음을 선택합니다.

  4. 생성(Create)을 선택합니다.

중요

두 단계가 모두 필요합니다. 확장을 생성하지 않고 확장 액세스만 구성하면 엔터프라이즈 로그인을 사용할 수 없으며 사용자에게 “빠른 데스크톱용 엔터프라이즈 로그인이이 계정에 대해 구성되지 않았습니다.”라는 오류가 표시됩니다.

참고

확장을 생성하는 것은 일회성 계정 수준 작업입니다. 관리자가 확장을 생성하면 계정의 모든 사용자가 엔터프라이즈 로그인을 사용할 수 있습니다. 개별 사용자는 확장 프로그램을 직접 활성화할 필요가 없으며 데스크톱 애플리케이션을 다운로드하고 로그인하기만 하면 됩니다.

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

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

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

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

문제 해결

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로 다시 생성합니다.

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

이 오류는 확장 액세스가 생성되었지만 확장 자체는 생성되지 않았음을 의미합니다. 관리 콘솔에서 앱 및 데이터 연결 → 확장으로 이동하여 이전에 구성한 확장 액세스를 선택하여 확장을 생성합니다.

사용자 정보 요청 실패(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 클레임을 생성해야 합니다.