인증

Public API를 사용하기 위해 OAuth가 반드시 필요한 것은 아닙니다. 비공개 서버 측 통합이라면 범위가 지정된 API 키로 시작하고 빠른 시작을 따르십시오. 보안 정책에서 수명이 짧은 액세스 토큰을 요구하거나 사용 중인 통합 플랫폼이 이미 해당 플로우를 지원하는 경우에는 OAuth 클라이언트 자격 증명을 선택하십시오. 두 방식 모두 서비스 계정을 사용합니다. 서비스 계정은 통합의 ID이며, 별도의 세 번째 인증 방식이 아닙니다.

​

구성 요소의 관계

통합마다 서비스 계정을 하나씩 생성하십시오. 해당 계정에 대해 API 키 또는 OAuth 클라이언트 중 하나를 선택하십시오. 각 API 요청에 두 방식을 모두 사용할 필요는 없습니다. 어느 자격 증명도 계정의 현재 권한을 초과할 수 없습니다. 빠른 시작에서는 Basic 인증을 사용합니다. API 키에는 Bearer 헤더도 사용할 수 있으며, 해당 헤더를 사용한다고 해서 OAuth 클라이언트가 필요하다는 의미는 아닙니다.

​

간단한 통합에는 API 키를 선택하십시오

자체 예약 작업, 보고 스크립트, 데이터 파이프라인 또는 기타 백엔드 서비스에서 시크릿 관리자에 저장된 시크릿이 보안 요구 사항에 부합한다면 API 키를 사용하십시오.

• 토큰 교환 없이 인증된 요청을 직접 보낼 수 있습니다.
• 워크로드에 필요한 권한만 선택하고 만료 시점을 설정하십시오.
• 중복 적용 기간을 활용하여 키를 교체하거나, 키가 노출된 경우 즉시 해지하십시오.

API 키 기반 통합에는 OAuth 클라이언트가 필요하지 않습니다. 빠른 시작으로 시작한 다음, 생성 및 교체 방법은 API 키를 참조하십시오.

​

수명이 짧은 액세스 토큰에는 OAuth를 선택하십시오

조직에서 만료되는 액세스 토큰을 요구하거나 통합 도구가 client_credentials 그랜트를 요구하는 경우, 기밀 백엔드 서비스에 OAuth 클라이언트 자격 증명을 사용하십시오.

1. 서비스 계정에 대해 범위가 지정된 OAuth 클라이언트를 생성합니다.
2. 설정 중에 제공된 클라이언트 인증 방식을 사용하여 리전별 토큰 엔드포인트에 클라이언트를 인증합니다.
3. 발급된 액세스 토큰을 API 요청과 함께 전송합니다. 현재 토큰이 만료되기 전에 새 토큰을 발급받으십시오.

OAuth를 사용하면 통합에 토큰 발급 및 만료 처리 로직이 추가됩니다. 클라이언트 시크릿은 여전히 안전하게 저장하고 교체해야 하며, 수명이 짧은 토큰을 사용한다고 해서 이 책임이 없어지지는 않습니다. 클라이언트 자격 증명 방식은 리프레시 토큰을 사용하지 않습니다. 새 액세스 토큰을 받으려면 클라이언트를 다시 인증하십시오. 조직에서 OAuth 액세스를 활성화해야 합니다. 활성화되어 있지 않은 경우 API 키를 사용하거나 요구 사항에 대해 Living Security 지원팀에 문의하십시오. 클라이언트 생성, 일회성 시크릿, 해지 및 복구에 대해서는 OAuth 클라이언트 자격 증명을 참조하십시오.

​

자격 증명은 백엔드에 보관하십시오

서비스 계정 API 키와 OAuth 클라이언트 시크릿은 서버 측 시크릿 저장소에 보관해야 합니다. 브라우저 코드, 모바일 앱, 소스 관리 또는 로그에 포함하지 마십시오. 서비스 계정 자격 증명은 워크로드로서 동작하며, 사용자를 로그인시키거나 고객 동의 플로우를 제공하지 않습니다. 어느 방식을 사용하든 조직에 해당하는 리전별 API 호스트를 사용하십시오. 인증 방식을 변경해도 리소스 URL, API 버전 또는 작업에 필요한 권한은 변경되지 않습니다.