OAuth 클라이언트가 암시적 권한 부여를 사용하지 못하도록 방지

릴리스 버전: Australia

업데이트 날짜 2026년 03월 12일

소요 시간: 2분

암시적 권한 부여 유형을 사용하지 않으려면 시스템 속성을 사용합니다.

OAuth 암시적 권한 부여는 CORS(교차 원본 리소스 공유)가 널리 채택되기 전에 브라우저와 클라이언트 측 애플리케이션(예: 단일 페이지 애플리케이션) 간의 제한을 극복하기 위해 만들어졌습니다. 특히 브라우저의 동일 원본 정책은 OAuth 인증 코드를 OAuth 액세스 토큰과 교환하는 요청을 차단했습니다. CORS 지원은 보편적이므로 OAuth 클라이언트는 암시적 권한 부여를 사용할 필요가 없으며 암시적 권한 부여 유형 요청은 기본적으로 실패합니다.

속성에 나열된 glide.oauth.clients.allowed.for.implicit.grant 클라이언트 ID는 암시적 권한 부여 유형을 계속 사용할 수 있습니다. 속성이 시스템 속성 [sys_properties] 테이블에 없거나 존재하지만 값을 포함하지 않는지 확인합니다.

중요사항:

OAuth 클라이언트를 다른 권한 부여 유형으로 변경하려면 클라이언트 애플리케이션(ServiceNow 플랫폼 외부)에서 코드 또는 구성을 변경해야 할 수 있습니다.

추가 정보


속성	설명
구성 이름	glide.oauth.clients.allowed.for.implicit.grant
구성 유형	시스템 속성(/sys_properties_list.do)
데이터 유형	문자열
권장 값	<공백>
기본값	<공백>
폴백 값	<공백>
범주	API 및 웹 서비스
보안 위험	심각도 점수: 3.9 CVSS 점수: 낮음 보안 위험 상세 정보: OAuth 암시적 권한 부여 유형으로 인해 권한 부여 서버가 권한 부여 응답 내에서 액세스 토큰을 발행하므로 액세스 토큰 유출 및 액세스 토큰 재생에 취약합니다. 즉, 공격자는 리소스 엔드포인트에서 유출되거나 도난당한 액세스 토큰을 사용할 수 있습니다. 암시적 권한 부여에서 권한 부여 서버는 URL 조각에 직접 액세스 토큰을 반환하므로 문제가 발생할 수 있습니다. 이 URL 조각은 브라우저 기록에 저장될 수 있습니다. 이후에 페이지가 이미지를 로드하거나 다른 도메인으로 연결되는 링크를 따라가는 경우 URL의 일부가 리퍼러 헤더를 통해 유출될 수 있습니다. 웹 서버, 부하 분산 장치 및 프록시가 전체 URL을 기록할 수 있습니다. 페이지에서 실행 중인 모든 JavaScript(악의적인 삽입된 JS 포함)는 `window.location.hash` 를 읽고 토큰을 추출할 수 있습니다. 이러한 문제를 방지하려면 인간/대화형 사용자가 클라이언트에 인증을 위임할 때 암시적 권한 부여 유형 대신 인증 코드 권한 유형을 사용합니다. 참조 RFC 9700, "OAuth 2.0 보안을 위한 현재 모범 사례" draft-ietf-oauth-v2-1-14, "OAuth 2.1 인증 프레임워크"
기능적 영향	암시적 권한 부여 유형 요청은 바로 사용 실패합니다. 속성에 추가되지 않은 암시적 권한 부여 유형의 OAuth 클라이언트는 기본적으로 실패합니다. 암시적 권한 부여 유형을 사용하는 OAuth 클라이언트를 정의하지 않은 경우 영향이 없습니다. 주: OAuth 클라이언트를 다른 권한 부여 유형으로 변경하려면 클라이언트 애플리케이션(ServiceNow 플랫폼 외부)에서 코드 또는 구성을 변경해야 할 수 있습니다.
의존성 및 필수 구성요소	없음