iOS/tvOS SDK 개요 iostvos-sdk-overview

소개 intro

iOS AccessEnabler는 모바일 앱에서 TV Everywhere의 권한 부여 서비스를 위해 Adobe Pass 인증을 사용할 수 있도록 해주는 Objective C iOS/tvOS 라이브러리입니다. 구현은 다음으로 구성됩니다. 액세스 활성 권한 부여 API 및 Entitydelegate 및 EntitlementStatus 라이브러리에서 트리거하는 콜백을 설명하는 프로토콜입니다. 프로토콜과 함께 인터페이스는 하나의 공통 이름인 AccessEnabler 라이브러리에서 참조됩니다.

iOS 및 tvOS 요구 사항 reqs

iOS 및 tvOS 플랫폼과 Adobe Pass 인증과 관련된 현재 기술 요구 사항은 을 참조하십시오. 플랫폼/장치/도구 요구 사항및 SDK 다운로드에 포함된 릴리스 노트를 참조하십시오. 이 페이지의 나머지 부분에서 특정 SDK 버전 이상에 적용되는 변경 사항을 설명하는 섹션이 보입니다. 예를 들어 다음은 1.7.5 SDK에 대한 적법한 참고 사항입니다.

기본 클라이언트 워크플로우 이해 flows

기본 클라이언트 워크플로우는 일반적으로 브라우저 기반 Adobe Pass 인증 클라이언트의 워크플로와 동일하거나 매우 유사합니다. 그러나 아래에 설명된 대로 몇 가지 예외가 있습니다.

초기화 후 워크플로 post-init

AccessEnabler에서 지원하는 모든 자격 부여 워크플로우는 이전에 을 호출했다고 가정합니다. setRequestor() 자신의 신분을 밝히기 위해 이 호출을 수행하면 일반적으로 애플리케이션의 초기화/설정 단계 중에 요청자 ID를 한 번만 제공합니다.

iOS 네이티브 클라이언트를 사용하여 setRequestor(), 진행 방법에 대한 선택 사항이 있습니다.

성공 알림을 기다리기 위해 앱을 대기하도록 선택할 수 있습니다. setRequestor() 또는 AccessEnabler의 콜 큐 메커니즘을 사용하도록 할 수도 있습니다. 모든 후속 인증 및 인증 요청에는 요청자 ID 및 관련 구성 정보가 필요하므로 setRequestor() 메서드는 초기화가 완료될 때까지 모든 인증 및 권한 부여 API 호출을 효과적으로 차단합니다.

일반 초기 인증 워크플로 generic

이 워크플로우의 목적은 MVPD로 사용자를 로그인하는 것입니다. 로그인에 성공하면 백엔드 서버가 사용자에게 인증 토큰을 발행합니다. 인증은 일반적으로 권한 부여 프로세스의 일부로 수행되지만, 다음은 인증이 개별적으로 작동하는 방법에 대한 설명이며, 권한 부여 단계는 포함하지 않습니다.

이 워크플로우는 기본 클라이언트마다 일반적인 브라우저 기반 인증 워크플로와 다르지만, 1~5단계는 기본 클라이언트와 브라우저 기반 클라이언트 모두에 대해 동일합니다.

로그아웃 워크플로 logout

기본 클라이언트의 경우, 로그아웃은 위에서 설명한 인증 프로세스와 유사하게 처리됩니다.

로그아웃 흐름은 사용자가 와 상호 작용할 필요가 없다는 점에서 인증 흐름과 다릅니다 UIWebView/WKWebView or SFSafariViewController 어떤 식으로든 컨트롤러입니다. 따라서 Adobe은 로그아웃 프로세스 중에 컨트롤을 보이지 않게(즉, 숨겨지도록) 만들 것을 권장합니다.

토큰 tokens

정의 및 사용 definitions

Adobe Pass 인증 권한 부여 솔루션은 인증 및 권한 부여 워크플로가 성공적으로 완료되면 Adobe Pass 인증이 생성하는 특정 데이터(토큰)를 생성하는 것에 중점을 둡니다. 이러한 토큰은 클라이언트의 iOS 디바이스에 로컬로 저장됩니다.

토큰의 수명은 제한됩니다. 만료 시 인증 및/또는 권한 부여 워크플로의 재시작을 통해 토큰을 재발행해야 합니다.

자격 워크플로 중에 발급되는 세 가지 유형의 토큰이 있습니다.

인증 및 인증에 성공하면 Adobe Pass 인증에서 인증, 권한 부여 및 수명이 짧은 미디어 토큰을 발행합니다. 이러한 토큰은 사용자의 장치에 캐시되어야 하며 관련 수명 기간에 사용되어야 합니다.

캐싱 지침 caching

인증 토큰

인증 토큰

AccessEnabler에서 RESOURCE당 하나의 인증 토큰만 캐시됩니다. 여러 인증 토큰이 캐시될 수 있지만 서로 다른 리소스와 연결되어 있습니다. 새 인증 토큰이 발급되고 에 대한 이전 인증 토큰이 이미 있을 때마다 동일한 리소스, 새 토큰이 기존 캐시된 값을 덮어씁니다.

미디어 토큰

단기 미디어 토큰은 전혀 캐시되지 않아야 합니다. 미디어 토큰은 일회성 사용으로 제한되므로 인증 API가 호출될 때마다 서버에서 검색해야 합니다.

지속성 persistence

토큰은 동일한 애플리케이션의 연속 실행 간에 지속적이어야 합니다. 즉, 인증 및 인증 토큰이 획득되고 사용자가 애플리케이션을 닫으면 사용자가 애플리케이션을 다시 열 때 애플리케이션에서 동일한 토큰을 사용할 수 있습니다. 더욱이, 이러한 토큰들은 다수의 애플리케이션들에 걸쳐 지속되는 것이 바람직하다. 즉, 사용자가 하나의 애플리케이션을 사용하여 특정 ID 공급자로 로그인한 후(인증 및 인증 토큰을 성공적으로 획득) 다른 애플리케이션을 통해 동일한 토큰을 사용할 수 있으며, 동일한 ID 공급자를 통해 로그인할 때 더 이상 자격 증명을 묻는 메시지가 표시되지 않습니다. 이러한 유형의 원활한 인증/권한 부여 워크플로우는 Adobe Pass 인증 솔루션을 진정한 TV Everywhere 구현으로 만드는 요소입니다.

iOS

iOS AccessEnabler 라이브러리는 토큰 데이터를 라는 "클립보드와 유사한" 데이터 구조에 저장하여 교차 애플리케이션 데이터 공유 문제를 해결합니다. 보드 붙여넣기. 이 시스템 수준 공유 리소스는 원하는 영구 토큰 사용 사례를 구현할 수 있는 주요 구성 요소를 제공합니다.

토큰 캐시에 특정 토큰을 배치하면 AccessEnabler 라이브러리에서 해당 토큰의 유효성을 다른 시간에 확인합니다. 유효한 토큰은 다음과 같이 정의됩니다.

tvOS

tvOS에서는 대지를 사용할 수 없으므로 tvOS AccessEnabler 라이브러리는 NsUserDefaults를 스토리지 옵션으로 사용합니다. 이는 인증 및 인증 토큰이 지속되는 문제를 해결하지만 저장된 정보를 상이한 애플리케이션 간에 공유할 수 없다.

iOS 10 임시 보드 변경 사항 - 이전 버전의 iOS에서 업그레이드하는 경우 대지가 지워집니다. 즉, 모든 애플리케이션을 다시 인증해야 합니다.

iOS 7 대지 변경 사항 - iOS 7에서 페이스트보드가 작동하는 방식의 변경으로 인해 iOS 7에서 실행되는 애플리케이션 간 교차 SSO가 제한됩니다. 동일한 애플리케이션을 사용하는 애플리케이션 <Bundle Seed ID>(또한으로 알려짐) <Team ID>)는 토큰을 공유합니다. 즉, 동일한 프로그래머 X의 앱 A1 및 A2는 토큰을 공유하는 반면, 앱 A1(프로그래머 X) 및 앱 A3(프로그래머 Y)은 토큰을 공유하지 않습니다.

iOS 7 이상 버전에서 SSO를 구성하는 방법에 대한 자세한 내용은 이 기술 노트를 참조하십시오(기술 노트는 Access Enabler v1.8 이상에 적용됨). https://tve.zendesk.com/entries/58233434-Configuring-Pay-TV-pass-SSO-on-iOS

토큰 스토리지(AccessEnabler 1.7)

AccessEnabler 1.7부터 토큰 스토리지는 여러 인증 토큰을 보유할 수 있는 다중 레벨 중첩 맵 구조에 따라 여러 프로그래머-MVPD 조합을 지원할 수 있습니다. 이 새로운 스토리지는 AccessEnabler 공용 API에 영향을 주지 않으며 프로그래머 측에서는 변경할 필요가 없습니다. 다음은 이 새로운 기능을 보여주는 예입니다.

이전 버전의 AccessEnabler에서는 토큰 저장소가 이전에 하나의 인증 토큰만 지원했으므로 6단계에서 사용자를 인증되지 않은 것으로 렌더링했습니다.

한 프로그래머/MVPD 세션에서 로그아웃하면 장치의 다른 프로그래머/MVPD 인증 토큰을 모두 포함하여 기본 저장소 전체가 지워집니다. 반면, 인증 흐름을 취소하는 경우(호출) setSelectedProvider(null))는 기본 저장소를 지우지 않지만, 현재 프로그래머/MVPD 인증 시도에만 영향을 미칩니다(현재 프로그래머에 대한 MVPD 삭제).

토큰 가져오기(AccessEnabler 1.7)

AccessEnabler 1.7에 포함된 또 다른 스토리지 관련 기능을 사용하면 이전 스토리지 영역에서 인증 토큰을 가져올 수 있습니다. 이 "Token Importer"를 사용하면 스토리지 버전이 업그레이드되어도 SSO 상태를 유지하면서 연속적인 AccessEnabler 릴리스 간의 호환성을 유지할 수 있습니다. 가져오기는 다음 기간 동안 실행됩니다. setRequestor() 흐름 및 실행은 다음 두 가지 시나리오에서 수행됩니다(현재 프로그래머에 대한 유효한 인증 토큰이 현재 저장소에 없다고 가정).

가져오기 작업은 프로그래머에게 투명하며 클라이언트 애플리케이션에서 코드를 변경할 필요가 없습니다.

토큰 삭제기(AccessEnabler 1.7.5)

AccessEnabler 1.7.5에서 이 서비스는 다음에 실행됩니다. setRequestor(). 추적을 위해 WiFi MAC 주소에서 IDFA로 iOS 7이 전환되어 개발되었습니다. 삭제기는 현재 저장소에 유효한 인증 토큰(이전에 iOS7 이전에 MAC 주소를 사용하여 계산된 장치 ID 측면에서 유효함)만 포함되어 있는지 확인합니다. 토큰 삭제기는 모든 잘못된 토큰을 제거합니다.

토큰 삭제기 서비스는 iOS 6에서 AccessEnabler 1.7.5 애플리케이션을 사용한 다음 사용자가 iOS 7로 업데이트할 때 가장 유용합니다. 이렇게 되면 iOS 6에서 얻은 모든 인증 토큰이 무효화됩니다(MAC 주소를 사용하던 것에서 IDFA로 장치 ID 알고리즘 변경 사항 때문). 삭제기가 모든 잘못된 토큰을 지우고 사용자는 인증되지 않습니다.

토큰 삭제기가 잘못된 토큰을 제거하지 않으면 AccessEnabler는 잘못된 인증 토큰이 있기 때문에 인증을 받지 못합니다. 인증 오류 메시지는 명확하지 않고 문제의 원인을 파악하는 데 너무 유용하지 않을 수 있으므로 최종 사용자가 디버깅하는 것이 까다로울 수 있습니다.

형식 format

AuthN 및 AuthZ 토큰의 형식은 백그라운드 정보용으로만 여기에 포함됩니다. 이러한 토큰의 구조는 언제든지 Adobe Pass 인증에 의해 변경될 수 있습니다. AuthN 및 AuthZ 토큰이 로컬 장치에 노출되지 않으므로 프로그래머는 앱을 구현하기 위해 AuthN 및 AuthZ 토큰의 정확한 구조를 알 필요가 없습니다. 짧은 미디어 토큰 은(는) 프로그래머 애플리케이션에 노출됩니다.

인증 토큰 authn_token

아래 목록은 인증 토큰의 형식을 제공합니다.

  <signatureInfo>base64(...)<signatureInfo>
  <simpleAuthenticationToken>
      <simpleTokenAuthenticationGuid>71C69B91-F327-F185-F29E-2CE20DC560F5</simpleTokenAuthenticationGuid>
      <simpleTokenRequestorID>TEST_REQUESTOR</simpleTokenRequestorID>
      <simpleTokenDomainName>adobe.com</simpleTokenDomainName>
      <simpleTokenExpires>2011/03/19 02:29:34 GMT +0200</simpleTokenExpires>
      <simpleTokenMsoID>Adobe</simpleTokenMsoID>
      <simpleTokenDeviceID>
          <simpleTokenFingerprint>
              HASH(true device identification info)
          </simpleTokenFingerprint>
      </simpleTokenDeviceID>
  </simpleAuthenticationToken>

인증 토큰 authz_token

아래 목록은 인증 토큰의 형식을 제공합니다.

  <signatureInfo>base64(...)<signatureInfo>
  <simpleAuthorizationToken>
      <simpleTokenRequestorID>TEST_REQUESTOR</simpleTokenRequestorID>
      <simpleTokenResourceID>TEST_RESOURCE</simpleTokenResourceID>
      <simpleTokenTTL>2011/03/17 14:40:08 GMT +0200</simpleTokenTTL>
      <simpleTokenMsoID>Adobe</simpleTokenMsoID>
      <simpleTokenDeviceID>
          <simpleTokenFingerprint>
              HASH(true device identification info)
          </simpleTokenFingerprint>
      </simpleTokenDeviceID>
  </simpleAuthorizationToken>

짧은 미디어 토큰 short_token

아래 목록은 짧은 미디어 토큰의 형식을 제공합니다. 이 토큰은 프로그래머 애플리케이션에 노출됩니다. 이것은 성공적인 자격 프로세스가 끝나면 프로그래머 애플리케이션에 전달됩니다.

  <signatureInfo>signature<signatureInfo>
  <shortAuthorizationToken>
    <sessionGUID>session_guid</sessionGUID>
    <requestorID>requestor_id</requestorID>
    <resourceID>resource_id</resourceID>
    <ttl>ttl_in_ms</ttl>
    <issueTime>issue_time</issueTime>
    <mvpdId>mvpd_id</mvpdId>
    <proxyMvpdId>proxy_mvpd_id</proxyMvpdId>
  </shortAuthorizationToken>

장치 바인딩 device_binding

위의 XML 목록에서 제목이 있는 태그를 참고하십시오 simpleTokenFingerprint. 이 태그의 목적은 기본 장치 ID 개별화 정보를 보유하는 것입니다. AccessEnabler 라이브러리는 이러한 개별화 정보를 가져와 권한 부여 호출 중에 Adobe Pass 인증 서비스에서 사용할 수 있도록 할 수 있습니다. 이 서비스는 이 정보를 사용하여 실제 토큰에 포함하므로 토큰을 특정 장치에 효과적으로 바인딩합니다. 이것의 최종 목표는 여러 디바이스에서 토큰을 전송할 수 없도록 하는 것입니다.

이는 명백히 보안 관련 기능이므로 이 정보는 보안 관점에서 본질적으로 "민감합니다". 결과적으로 이러한 정보는 변조 및 도청으로부터 보호될 필요가 있다. 도청 문제는 HTTPS 프로토콜을 통해 인증/권한 부여 요청을 전송하여 해결됩니다. 변조 방지는 기기 식별 정보에 디지털 서명을 함으로써 처리된다. AccessEnabler 라이브러리는 디바이스에서 제공하는 정보에서 디바이스 ID를 계산한 다음, 디바이스 ID를 "in the clear"를 요청 매개 변수로 Adobe Pass 인증 서버에 보냅니다. Adobe Pass 인증 서버는 Adobe의 개인 키로 장치 ID를 디지털 서명하고 AccessEnabler에 반환되는 인증 토큰에 추가합니다. 따라서 장치 ID가 인증 토큰과 바인딩됩니다. 인증 흐름 중에 AccessEnabler는 인증 토큰과 함께 디바이스 ID를 지우고 다시 전송합니다. 유효성 검사 프로세스가 실패하면 자동으로 인증/권한 부여 워크플로가 실패합니다. Adobe Pass 인증 서버는 개인 키를 장치 ID에 적용하고 인증 토큰의 값과 비교합니다. 일치하지 않으면 해당 권한 흐름이 실패합니다.

AccessEnabler 1.7.5의 디바이스 바인딩에 대한 참고 사항: AccessEnabler 1.7.5부터 iOS 디바이스에 대한 개별화 정보를 제공하기 위해 디바이스 ID를 계산하는 방법이 변경되었습니다. 이 변경 사항은 iOS 7의 변경 사항을 반영합니다. iOS 7부터 Apple은 IDFA(광고주용 식별자)를 위해 더 이상 WiFi MAC 주소를 추적 옵션으로 제공하지 않습니다. iOS 7에서 실행되는 앱의 개별화 정보는 IDFA를 기반으로 하며 해당 정보는 자격 흐름 토큰에 포함되어 있으므로 이러한 변경으로 인해 발생할 수 있는 사용자 경험에 여러 가지 영향을 줄 수 있습니다. 사용자가 업그레이드하고 있는 iOS 버전과 프로그래머가 업그레이드하고 있는 AccessEnabler 버전이 서로 다르기 때문입니다. 이 변경 사항에 대한 자세한 내용은 AccessEnabler SDK 1.7.5에 포함된 릴리스 노트를 참조하십시오.