REST API 개요 rest-api-overview
Last update: Wed Mar 13 2024 00:00:00 GMT+0000 (Coordinated Universal Time)
이 페이지의 컨텐츠는 정보용으로만 제공됩니다. 이 API를 사용하려면 Adobe의 현재 라이선스가 필요합니다. 허가되지 않은 사용은 허용되지 않습니다.
개요 over
Adobe Pass 인증 REST API는 TV Everywhere(TVE) 인증 및 권한 부여 서비스에 직접 액세스할 수 있도록 합니다. 이 API는 서버 간 또는 연결된 장치(예: 게임 콘솔, 스마트 TV, 셋톱 박스 등)의 두 가지 기본 아키텍처를 지원합니다. 웹 검색 기능이 없는 응용 프로그램입니다.
조절 메커니즘
Adobe Pass 인증 REST API는 조절 메커니즘.
서버 간
서버 간 솔루션에는 TVE 흐름을 위해 Adobe Pass 인증 서비스와 연결하는 프로그래머 서비스와 통합하는 프로그래머 클라이언트 애플리케이션이 포함됩니다. 이 접근 방식은 대부분의 TVE 구현을 클라이언트에서 단일 통합 인증 모듈을 구축 및 유지 관리할 수 있는 서버로 전환합니다. 클라이언트 애플리케이션의 나머지 주요 권한은 사용자 인증을 위한 웹 보기 관리입니다.
연결된 장치
연결된 장치 앱은 REST API를 통해 Adobe Pass 인증과 직접 통신하여 구성, 등록, 인증 상태 확인 및 인증 흐름을 수행하는 반면 인증 흐름에는 두 번째 화면(브라우저) 앱이 필요합니다. 따라서 기본 SDK는 사용되지 않습니다.
기타 아키텍처
스마트 디바이스를 위한 서버-대-서버 및 직접 클라이언트 솔루션인 두 가지 주요 REST API 기반 아키텍처 외에도 다른 아키텍처가 있습니다. 그 중 주요 아키텍처는 Adobe Pass 인증이 프로그래머에게 제공하는 액세스 Enabler라는 클라이언트 구성 요소를 사용하는 SDK 아키텍처입니다. 이 앱은 Access Enabler API를 사용하여 시작, 인증, 권한 부여 및 로그아웃을 처리합니다. 프로그래머 앱과 Adobe Pass 인증 서버 간의 모든 통신은 Access Enabler를 통해 수행됩니다. JavaScript, iOS, tvOS, Android 및 FireTV 플랫폼에서는 다른 버전의 Access Enabler를 사용할 수 있습니다.
서버 간 솔루션 외부에서 기본 SDK를 지원하는 클라이언트 플랫폼에서 REST API를 직접 사용할 수는 있지만 이 접근 방식은 권장되지 않습니다.
REST API 장단점 ProsAndCons
Adobe Pass 인증 REST API는 웹 검색 기능이나 영구 저장소가 없는 장치를 위한 TV Everywhere(TVE) 솔루션을 제공하기 위해 생성되었습니다. REST API는 모든 인증 및 권한 부여 흐름에 대한 지원을 제공하지만, 기본 SDK 구성 요소가 없기 때문입니다. Adobe Pass 인증에서 제공하고 유지 관리하는 SDK에는 비즈니스 규칙을 구현하는 기본 기능이 포함되어 있습니다. REST API의 경우 프로그래머가 구현하고 유지 관리해야 합니다. 아래 프로그래머 책임 표에서 프로그래머가 해결해야 하는 현재 REST API의 제한 사항을 설명합니다.
서버 대 서버 및 클라이언트 기반 장단점
서버 간 아키텍처는 대부분의 인증 및 권한 부여 관련 로직을 단일 논리 유닛 또는 구현으로 통합하는 방법을 제공합니다. 이 접근법은 장단점이 있다. 장점에는 다음이 포함됩니다.
- 인증 및 권한 부여 비즈니스 논리에 대한 단일 구현.
- 지원되는 각 플랫폼에서 해당 플랫폼 기본 도구를 사용하여 해당 논리를 구현할 필요가 없습니다.
- 연결된 모든 요구 사항(예: 앱스토어 업데이트)으로 클라이언트를 업데이트하지 않고도 기능을 업데이트할 수 있습니다.
- 보다 쉽게 및 사용자 지정 authN 및 authZ 기능 확장(예: D2C 추가)
- 더 나은 제어, 품질 및 모니터링을 위해 관련 트래픽을 직접 관리합니다.
단점은 프로그래머의 책임에 나열되어 있지만 다음을 포함합니다.
- 플랫폼 SSO가 없는 플랫폼의 경우 각 클라이언트에 대해 SSO를 구현해야 합니다.
- 프로그래머는 필요한 경우 MVPD 관련 논리를 구현해야 합니다.
- REST API를 사용하는 모든 플랫폼은 인증 TTL과 같은 속성을 관리하는 단일 구성을 공유합니다.
연결된 장치
대부분의 연결된 장치의 경우 SDK를 사용할 수 없으므로 REST API를 한 가지 방법 또는 다른 방법으로 사용해야 합니다. 연결된 장치는 REST API를 직접 사용하거나 REST API를 사용하는 서버 간 솔루션과 통합됩니다.
프로그래머 책임 programmer-responsibilities
다음은 서버 간 및 연결된 장치 응용 프로그램 모두에 적용됩니다.
기능
기능 처리 담당
현재 클라이언트 없는 API의 제한 사항 및 기본 SDK와의 차이점에 대한 설명
플랫폼별로 적용된 구성 설정
Adobe
1개
주요 제한 모든 플랫폼(iOS 및 Android와 같은 모바일 장치 포함)에서 REST API를 사용할 때 TVE Dashboard 구성 도구의 REST API에 해당하는 구성 설정이 모든 장치에 적용됩니다(REST API 위에 구현된 기본 애플리케이션을 실행하는 iOS 장치가 있더라도). 이 제한 사항
깨질 수 있음 MVPD와 합의한 TTL 및 플랫폼 설정(각 플랫폼마다 다른 경우).
1
단일 사인온
프로그래머
REST API를 사용하면 SSO는 플랫폼 SSO를 지원하는 플랫폼(예: Apple, Roku, Amazon)에서만 사용할 수 있으며, REST API를 사용할 때는 다른 플랫폼에 대해 SSO를 보장할 수 없습니다. SDK는 사이트/앱 간 방식으로 데이터를 캐시합니다. 즉, 사용자가 사이트/앱에 한 번 로그인하고 필요한 사용자 상호 작용 없이 참여 사이트에 이미 로그인되어 있습니다.
2
단일 로그아웃
프로그래머
기본 SDK SSO 시나리오에서는 참여하는 응용 프로그램 하나에서 로그아웃하면 모든 곳에서 사용자가 로그아웃됩니다. 현재 SLO를 지원하지 않는 REST API에서는 한 애플리케이션에서 로그아웃하면 해당 특정 애플리케이션에 대해서만 사용자가 로그아웃됩니다.
캐싱
프로그래머
REST API 구현은 비즈니스 동의 데이터 항목에 대한 자체 캐싱 메커니즘을 구현해야 합니다. SDK는 다양한 비즈니스 규칙을 고려하면서 다양한 데이터 항목을 자동으로 캐싱합니다. 예를 들어 사용자 메타데이터는 인증 토큰과 동일한 TTL로 캐시되지만 일부 항목은 캐싱에서 프로그래밍 방식으로 제외될 수 있습니다(preflight).
자세한 오류 보고 메커니즘
프로그래머
REST API는 주로 애플리케이션 오류 보고를 위해 HTTP 오류 코드를 사용하는 반면, SDK에는 애플리케이션 개발자가 발생한 상황을 더 잘 이해할 수 있도록 지원하는 자세한 오류 보고 메커니즘이 있습니다.
응용 프로그램 오류 복구(오류 시 다시 시도, 루프 감지 등)
프로그래머
REST API 구현은 자체 애플리케이션 복구 시스템을 구축해야 하지만 SDK를 기반으로 한 구현은 SDK 오류 복구 시스템의 이점을 활용합니다. 즉, 즉각적인 논리를 사용하여 특정 네트워크 호출을 다시 시도하여 "루프"를 방지하여 일시적인 네트워크 오류에서 복구합니다.
요청자별 인증
프로그래머
일부 MVPD는 업무상 또는 기술적 문제로 인해 각 사이트/앱에 대한 인증이 필요합니다. SDK는 TVE 대시보드 구성을 기반으로 이 기능을 자동으로 적용합니다. REST API 구현자는 비즈니스 계약을 위반하지 않도록 또는 애플리케이션별로 인증 데이터의 범위를 지정하는 MVPD에 대한 인증을 완료할 수 있도록 이 기능을 직접 구현해야 합니다.
수동 인증
프로그래머
일부 MVPD는 사용자가 자격 증명을 입력할 필요가 없고 사용자를 자동으로 인증하려는 "수동" 인증을 지원합니다. 이 기능은 "요청자별 인증"도 필수로 사용하는 MVPD에 특히 유용합니다. 이러한 경우 SDK에서 사용할 수 있는 UX가 원활하며, 사용자가 애플리케이션에서 한 번만 인증하고 SDK가 에코시스템의 다른 애플리케이션에 대해 "수동" 인증을 수행합니다. 사용자는 추가 수동 호출을 보지 않고 단순히 이미 인증되는 반면 MVPD는 각 애플리케이션에 대해 별도의 인증 세션을 갖는 목표를 달성합니다.
암시적이고 균일한 장치 감지
프로그래머
SDK는 장치 유형을 자동으로 감지하고 표준 방식으로 해당 정보를 전송합니다. REST API 구현은 구현자에 따라 다른 정보를 보내는 경향이 있으므로 사이트 간에 비즈니스 규칙 및 통계를 왜곡하거나 왜곡합니다. 프로그래머들은 우리에게 올바른 기기 정보를 보냈는지 확인해야 한다 각 앱에서. 서버 간 구현의 경우, 추가 단계를 수행하지 않는 한 REST API가 최종 사용자의 IP 주소를 올바르게 식별하지 않습니다. IP 주소는 사기 방지나 HBA와 같은 특정 사용 사례에서 중요합니다.
변조 불가능한 TempPass
프로그래머
TempPass 적용은 안정적인 장치 ID를 기반으로 합니다. SDK는 하드웨어 정보/지문 기술을 사용하여 디바이스를 식별하며 이 메커니즘은 공개되지 않으므로 보다 안전하고 충돌이 없습니다. REST API 구현의 경우 프로그래머는 장치 식별/지문을 위한 자체 알고리즘을 구현해야 합니다.
장치 바인딩
프로그래머
SDK를 통해 애플리케이션을 사용하는 디바이스에서 생성된 토큰은 이동할 수 없으므로 악의적인 사용자가 자신의 토큰을 공유하고 다른 사용자에게 액세스 권한을 제공하기 어렵습니다. 이는 "변조 방지 TempPass"와 동일한 장치 ID 메커니즘을 기반으로 합니다. REST API의 경우 토큰은 클라우드에 유지되므로 동일한 디바이스 ID를 사용하여 동일한 호출을 수행하는 두 디바이스의 응답/액세스가 동일합니다. 프로그래머는 deviceID를 생성/할당하기 위한 강력하고 안전하며 충돌하지 않는 메커니즘을 가지고 있는지 확인해야 합니다.
예측 가능하고 인증된 기능 세트
프로그래머
각 SDK의 기존 기능 세트는 일관되고, 예측 가능하며, 완전히 인증되고 테스트되었습니다. 일부 비즈니스 요구 사항은 SDK를 통해 적용되므로 프로그래머가 REST API를 사용하는 동안 계약을 위반하는 것은 위험합니다. REST API가 보다 유연할 수 있지만 Adobe은 SDK 구현이 TVE 대시보드의 비즈니스 의사 결정 및 설정을 적용하도록 보장합니다. Clientless의 경우 각 프로그래머는 지정된 시점에 애플리케이션을 설정하는 비즈니스 규칙의 하위 집합을 구현합니다.
-
새로운 One API 이니셔티브의 일부로, 이 제한을 수정하고 장치 식별을 기반으로 플랫폼당 규칙을 적용할 수 있도록 계획합니다.
-
Adobe은 모든 주요 플랫폼과 계속 작동하여 REST API와 함께 사용할 수 있는 Platform SSO를 구현합니다. One API 이니셔티브는 기본 SDK를 사용하여 구현된 앱과 REST API를 사용하여 구현된 앱 간의 SSO 지원을 제공합니다.
최소 장치 요구 사항 min_reqs
Adobe Pass 인증 REST API를 사용하려면 장치가 의 REST API 섹션에 나열된 최소 기술 요구 사항을 충족하거나 초과해야 합니다. Adobe Pass 인증 플랫폼/장치/도구 요구 사항 문서.