OAuth 인바운드

  • 릴리스 버전: Zurich
  • 업데이트 날짜 2025년 07월 31일
  • 소요 시간: 4분

    • OAuth 인바운드 인증을 사용하면 신뢰할 수 있는 외부 애플리케이션이 ServiceNow API에 안전하게 액세스할 수 있으므로 제어되고 인증된 연결을 보장할 수 있습니다.

    시스템에서 OAuth 통합을 구성하거나 관리하려면 다음 역할 중 하나가 있어야 합니다.
    • oauth_admin
    • mi_admin
    • admin

    인바운드 인증을 사용하면 타사 시스템 또는 기타 ServiceNow® 인스턴스와 같은 외부 애플리케이션이 API에 안전하게 연결할 수 있습니다 ServiceNow . 인바운드 인증은 신뢰할 수 있는 클라이언트만 통제되고 안전한 방식으로 ServiceNow 인스턴스에 액세스할 수 있음을 확인합니다. ServiceNow 는 각각 특정 통합 시나리오를 위해 설계된 여러 OAuth 2.0 권한 유형을 지원합니다. 다음 정보를 사용하여 사용 사례에 가장 적합한 권한 부여 유형을 선택합니다.

    인증 코드 부여

    이상적인 사용 시나리오 기능
    사용자의 동의 하에 사용자를 대신하여 사용자 데이터에 액세스해야 하는 애플리케이션입니다.

    예를 들어 사용자를 대신하는 웹, 모바일 또는 데스크톱 애플리케이션입니다.

    		 사용자는 클라이언트 애플리케이션에서 로그인 프로세스를 시작하여 로그인 페이지로 리디렉션 ServiceNow 합니다. 사용자가 로그인하고 동의를 부여하면 클라이언트 애플리케이션이 인증 코드를 받습니다. 클라이언트 애플리케이션은 권한 부여 코드를 액세스 토큰에 대한 인스턴스와 ServiceNow 교환합니다.

    인증 코드 부여는 사용자 대면 통합에 가장 안전하고 널리 사용되는 워크플로우입니다. 기밀 클라이언트(클라이언트 암호 포함)와 PKCE(Proof Key for Code Exchange)를 사용하는 공용 클라이언트를 모두 지원합니다.

    인증 코드 부여 워크플로우 및 구성에 대한 자세한 내용은 다음을 참조하십시오. 인증 코드 부여

    클라이언트 자격 증명 부여

    이상적인 사용 시나리오 기능
    사용자 개입 없이 API에 액세스 ServiceNow 해야 하는 백엔드 서비스 또는 자동화된 시스템 통합과 같은 클라이언트 애플리케이션입니다. 클라이언트 애플리케이션은 자체 자격 증명(클라이언트 ID 및 비밀)을 ServiceNow 사용하여 인스턴스와 직접 인증합니다. 인증되면 애플리케이션은 API에 액세스할 수 있는 ServiceNow 액세스 토큰을 받습니다.

    클라이언트 자격 증명 부여 워크플로우 및 구성에 대한 자세한 내용은 다음 문서를 참조하십시오 클라이언트 자격 증명 부여.

    외부 공급업체 ID 토큰 플로우

    이상적인 사용 시나리오 기능
    ServiceNow AD Azure 또는 Okta. 클라이언트 애플리케이션은 신뢰할 수 있는 타사 ID 제공자로부터 ID 또는 액세스 토큰을 얻고 인스턴스에 대한 API 요청을 ServiceNow 할 때 인증 헤더에 포함합니다. ServiceNow 토큰을 확인하고 신뢰할 수 있는 경우 어설션하는 ID를 기반으로 액세스 권한을 부여합니다. 이를 통해 시스템 전반에 걸쳐 원활한 1회 사용자 인증(SSO) 및 연합 인증이 가능합니다.

    외부 공급업체 토큰 플로우 및 구성에 대한 자세한 내용은 단원을 참조하십시오외부 공급업체 토큰 부여.

    JWT 전달자 보조금

    이상적인 사용 시나리오 기능
    사용자 상호 작용이나 공유 암호 저장 없이 사용자 대신 또는 사용자 자신으로 자원에 ServiceNow 안전하게 액세스해야 하는 클라이언트 애플리케이션.

    클라이언트 애플리케이션은 나타내는 사용자 또는 시스템과 같은 ID 관련 클레임을 포함하는 서명된 JWT(JSON Web Token)를 만듭니다. 그런 다음 접근 토큰을 요청하기 위해 인스턴스에 제공합니다 ServiceNow .
    사용자를 대신해 작업하는 경우:
    토큰은 이전에 인증된 사용자를 나타냅니다. 이렇게 하면 사용자에게 자격 증명이나 동의를 다시 묻지 않고 안전하고 원활하게 액세스할 수 있습니다. 서명된 토큰은 사용자의 ID를 어설션하여 실시간 사용자 상호 작용 없이 요청을 신뢰할 수 있도록 합니다 ServiceNow .
    자체적으로 작동하는 경우:
    토큰은 클라이언트 애플리케이션을 직접 식별하고 인증합니다. 공유 암호를 사용하는 대신 클라이언트는 개인 키로 토큰에 서명하므로 클라이언트 자격 증명 부여에 대한 보다 안전한 대안이 됩니다.

    JWT 전달자 권한 워크플로우 및 구성에 대한 자세한 내용은 문서를 참조하십시오 JSON 웹 토큰 전달자 권한 부여.

    자원 소유자 암호 자격 증명 부여

    이상적인 사용 시나리오 기능
    앱이 사용자의 자격 증명을 직접 수집하는 통제된 환경에서 매우 신뢰할 수 있는 내부 클라이언트 애플리케이션입니다. 클라이언트 애플리케이션은 사용자의 사용자 이름과 암호를 수집하고 액세스 토큰을 얻기 위해 인스턴스로 ServiceNow 리디렉션합니다. 워크플로우는 리디렉션 및 동의 화면을 무시하지만 사용자 자격 증명을 클라이언트 애플리케이션에 노출합니다. ServiceNow 는 레거시 또는 통제된 환경에서만 자원 소유자 암호 자격 증명 권한을 구현하는 것을 권장합니다.

    자원 소유자 암호 자격 증명 부여 워크플로우 및 구성에 대한 자세한 내용은 문서를 참조하십시오 자원 소유자 암호 자격 증명 부여.

    암시적 부여

    이상적인 사용 시나리오 기능
    클라이언트 비밀을 안전하게 저장할 수 없고 간단한 클라이언트 쪽 인증 흐름이 필요한 레거시 SPA(단일 페이지 애플리케이션) 또는 브라우저 기반 앱입니다. 사용자는 브라우저를 통해 로그인합니다. 클라이언트 애플리케이션은 중간 인증 코드 단계를 바이패스하여 로그인 후 URL에서 직접 액세스 토큰을 받습니다.

    이 흐름은 원래 비밀을 안전하게 저장할 수 없는 브라우저에서 완전히 실행되는 공용 클라이언트를 위해 설계되었습니다. 구현을 단순화하지만 브라우저에 토큰을 노출하여 가로채기 위험을 높입니다. 보안을 강화하려면 ServiceNow PKCE를 사용하여 권한 부여 코드 부여를 구현하는 것이 좋습니다.

    암시적 허용 워크플로우 및 구성에 대한 자세한 내용은 다음 문서를 참조하십시오 OAuth 암시적 부여.

    OAuth 범위

    REST API에 대한 OAuth 인증 범위 지원의 범위를 지정할 수 있습니다. OAuth 범위는 특정 REST API에 대한 액세스만 제공합니다. 자세한 내용은 REST API 인증 범위 문서를 참조하십시오.