REST API V2常見問題集
- 主題：
- 驗證
重要本檔案提供與Adobe Pass驗證REST API V2採用相關常見問題的高度概觀解答。
如需整體REST API V2的詳細資訊，請參閱REST API V2概觀檔案。
一般常見問答
如果您正在處理需要整合REST API V2的應用程式，不論是新應用程式或從REST API V1或SDK移轉的現有應用程式，請由此區段開始。
如需移轉詳細資訊和步驟的詳細資訊，請參閱下一節。
註冊階段常見問題集
註冊階段常見問題集
設定階段常見問題集
設定階段常見問題集
1.組態階段的用途為何？
設定階段的用途是向使用者端應用程式提供與其主動整合的MVPD清單，以及由Adobe Pass驗證針對每個MVPD儲存的設定詳細資料（例如，id、displayName、logoUrl等）。
當使用者端應用程式需要要求使用者選取他們的電視提供者時，「組態階段」會成為「驗證階段」的先決條件步驟。
2.設定階段是否為必要階段？
設定階段並非強制性，使用者端應用程式必須在使用者需要選取其MVPD以進行驗證或重新驗證時，才可擷取設定。
在下列情況下，使用者端應用程式可以略過此階段：
- 使用者已經過驗證。
- 透過基本或促銷TempPass功能提供使用者暫時存取。
- 使用者驗證已過期，但使用者端應用程式已快取先前選取的MVPD作為使用者體驗動機的選擇，而且只是提示使用者確認他們仍然是該MVPD的訂閱者。
3.什麼是設定？其有效期為多久？
設定是在字彙表檔案中定義的辭彙。
組態包含由下列屬性id、displayName、logoUrl等定義的MVPD清單，這些屬性可從組態端點擷取。
使用者端應用程式只有在使用者需要選取其MVPD以進行驗證或重新驗證時，才必須擷取設定。
當使用者需要選取電視提供者時，使用者端應用程式可使用設定回應，以呈現具有可用MVPD選項的UI選擇器。
使用者端應用程式必須儲存使用者選取的MVPD識別碼(如MVPD的組態層級id屬性所指定)，才能繼續驗證、預先授權、授權或登出階段。
如需詳細資訊，請參閱擷取組態檔案。
4.使用者端應用程式是否應該將組態回應資訊快取在永久儲存體中？
使用者端應用程式只有在使用者需要選取其MVPD以進行驗證或重新驗證時，才必須擷取設定。
使用者端應用程式應將設定回應資訊快取到記憶體儲存體中，以避免不必要的請求並改善使用者體驗，當：
- 使用者已經過驗證。
- 透過基本或促銷TempPass功能提供使用者暫時存取。
- 使用者驗證已過期，但使用者端應用程式已快取先前選取的MVPD作為使用者體驗動機的選擇，而且只是提示使用者確認他們仍然是該MVPD的訂閱者。
5.使用者端應用程式可以管理自己的MVPD清單嗎？
使用者端應用程式可以管理自己的MVPD清單，但必須使MVPD識別碼與Adobe Pass驗證保持同步。 因此，建議您使用Adobe Pass驗證提供的設定，以確保清單是最新且正確的。
如果提供的Adobe Pass識別碼無效，或是使用者端應用程式未與指定的服務提供者有效整合，使用者端應用程式將會從MVPD驗證REST API V2收到錯誤。
6.使用者端應用程式可以篩選MVPD清單嗎？
使用者端應用程式可以根據自己的商業邏輯和需求（例如使用者位置或先前選取的使用者歷史記錄），實作自訂機制，以篩選設定回應中提供的MVPD清單。
使用者端應用程式可以篩選TempPass MVPD的清單，或整合仍在開發或測試中的MVPD。
7.如果與MVPD的整合停用並標籤為非使用中，會發生什麼情況？
當與MVPD的整合停用並標籤為非使用中時，MVPD會從進一步設定回應中提供的MVPD清單中移除，您需考慮兩個重要後果：
- 該MVPD未經驗證的使用者將無法再使用該MVPD完成驗證階段。
- 該MVPD的已驗證使用者將無法再使用該MVPD完成預先授權、授權或登出階段。
如果使用者選取的Adobe Pass不再與指定的服務提供者有效整合，使用者端應用程式將會從MVPD Authentication REST API V2收到錯誤。
8.如果與MVPD的整合啟用回頭並標籤為使用中，會發生什麼情況？
當與MVPD的整合重新啟用並標籤為作用中時，MVPD會重新納入進一步設定回應中提供的MVPD清單中，您需考慮兩個重要後果：
- 該MVPD的未經驗證使用者將能夠再次使用該MVPD完成驗證階段。
- 該MVPD的已驗證使用者將能夠使用該MVPD再次完成預先授權、授權或登出階段。
9.如何啟用或停用與MVPD的整合？
您的組織管理員或代表您行事的Adobe Pass驗證代表可透過Adobe Pass TVE控制面板完成此作業。
如需詳細資訊，請參閱TVE儀表板整合使用手冊檔案。
驗證階段常見問題集
驗證階段常見問題集
1.驗證階段的用途為何？
「驗證階段」的目的是讓使用者端應用程式能夠驗證使用者的身分並取得使用者中繼資料資訊。
當使用者端應用程式需要播放內容時，「驗證階段」會成為「預先授權階段」或「授權階段」的先決條件步驟。
2. 「驗證階段」是否為必要？
驗證階段是強制性的，當使用者在Adobe Pass驗證中沒有有效的設定檔時，使用者端應用程式必須驗證使用者。
在下列情況下，使用者端應用程式可以略過此階段：
- 使用者已經過驗證，設定檔仍然有效。
- 透過基本或促銷TempPass功能提供使用者暫時存取。
使用者端應用程式錯誤處理需要處理錯誤代碼（例如，authenticated_profile_missing、authenticated_profile_expired、authenticated_profile_invalidated等），這表示使用者端應用程式需要使用者進行驗證。
3.什麼是驗證工作階段？其有效期限為多久？
驗證工作階段是在字彙表檔案中定義的辭彙。
驗證工作階段會儲存可從「工作階段」端點擷取的已起始驗證程式相關資訊。
驗證工作階段的有效時間有限，且在由notAfter時間戳記所指定的問題發生時很短，這表示在需要重新啟動流程之前，使用者必須完成驗證程式的時間長度。
使用者端應用程式可使用驗證工作階段回應，以瞭解如何進行驗證程式。 請注意，在某些情況下，使用者不需要驗證，例如提供暫時存取、存取效能降低，或使用者已經驗證。
如需詳細資訊，請參閱下列檔案：
4.什麼是驗證碼？其有效期為多久？
驗證代碼是字彙表檔案中定義的辭彙。
驗證代碼會儲存使用者啟動驗證程式時產生的唯一值，並唯一識別使用者的驗證工作階段，直到程式完成或驗證工作階段過期為止。
驗證程式碼的有效時間範圍僅限於起始驗證工作階段時指定的有限且較短的時間範圍（以notAfter時間戳記表示），這表示使用者在需要重新啟動流程之前必須完成驗證程式的時間量。
使用者端應用程式可使用驗證碼來驗證使用者是否已成功完成驗證，並擷取使用者的設定檔資訊，通常透過輪詢機制。
使用者端應用程式也可以使用驗證代碼，讓使用者在相同裝置或第二個（熒幕）裝置上完成或繼續驗證程式，因為驗證工作階段並未到期。
如需詳細資訊，請參閱下列檔案：
5.使用者端應用程式如何知道使用者是否輸入有效的驗證代碼，以及驗證工作階段是否尚未過期？
使用者端應用程式可以傳送要求給負責繼續驗證工作階段或擷取與驗證代碼關聯的驗證工作階段資訊的其中一個「工作階段」端點，來驗證使用者在次要（熒幕）應用程式中輸入的驗證代碼。
如果輸入的驗證碼錯誤或驗證工作階段過期，使用者端應用程式會收到錯誤。
如需詳細資訊，請參閱繼續驗證工作階段和擷取驗證工作階段檔案。
6.使用者端應用程式如何知道使用者是否已驗證？
使用者端應用程式可以查詢下列其中一個端點，該端點能夠驗證使用者是否已通過驗證並傳回設定檔資訊：
如需詳細資訊，請參閱下列檔案：
7.設定檔是什麼？其有效期為多久？
設定檔是在字彙表檔案中定義的辭彙。
設定檔會儲存有關使用者驗證有效性的資訊、中繼資料資訊以及可從「設定檔」端點擷取的更多資訊。
使用者端應用程式可使用設定檔來瞭解使用者的驗證狀態、存取使用者中繼資料資訊、尋找用於驗證的方法或用於提供身分識別的實體。
如需詳細資訊，請參閱下列檔案：
設定檔在被notAfter時間戳記查詢時指定的有限時間範圍內有效，這表示使用者在需要再次通過驗證階段之前具有有效驗證的時間量。
這個有限的時間範圍稱為驗證(authN) TTL，可由您的組織管理員或代表您行事的Adobe Pass驗證代表透過Adobe Pass TVE儀表板檢視及變更。
如需詳細資訊，請參閱TVE儀表板整合使用手冊檔案。
8.使用者端應用程式是否應該將使用者的設定檔資訊快取在永久儲存體中？
使用者端應用程式應將部分使用者設定檔資訊快取到永久性儲存體中，以避免不必要的請求，並改善使用者體驗，同時考慮到以下方面：
mvpd當目前的使用者設定檔過期時，使用者端應用程式可以使用記憶中的MVPD選項，並直接要求使用者確認。
attributesnotAfter使用者端應用程式錯誤處理需要處理錯誤代碼（例如，
authenticated_profile_missing、authenticated_profile_expired、authenticated_profile_invalidated等），這表示使用者端應用程式需要使用者進行驗證。9.使用者端應用程式可以擴充使用者的設定檔而不需要重新驗證嗎？
不適用。
使用者設定檔的到期時間是由使用MVPD建立的驗證TTL所決定，因此若沒有使用者互動，則無法延伸至超過其有效期限。
因此，使用者端應用程式必須提示使用者重新驗證，並與MVPD登入頁面互動，以重新整理我們在系統上的設定檔。
不過，對於支援家用驗證 (HBA)的MVPD，使用者不需要輸入認證。
10.每個可用設定檔端點的使用案例為何？
基本設定檔端點的設計是為了讓使用者端應用程式能夠知道使用者的驗證狀態、存取使用者中繼資料資訊、尋找用於驗證的方法或用於提供身分識別的實體。
每個端點皆適合特定使用案例，如下所示：
在此案例中，使用者端應用程式不會將使用者選取的MVPD識別碼快取到永久儲存體中。
因此，它將傳送單一要求以擷取所有可用的使用者設定檔。
在此情況下，使用者端應用程式必須將使用者先前選取的MVPD識別碼快取到永久儲存區。
因此，它會傳送單一要求，以擷取該特定MVPD的使用者設定檔。
在此案例中，使用者端應用程式必須判斷使用者是否已順利完成驗證，並擷取其設定檔資訊。
因此，它會啟動輪詢機制，以擷取與驗證碼相關聯的使用者設定檔。
如需詳細資訊，請參閱主要應用程式🔗內執行的基本設定檔流程，以及次要應用程式檔案內執行的基本設定檔流程。
設定檔SSO端點有不同的用途，它讓使用者端應用程式能夠使用合作夥伴驗證回應建立使用者設定檔，並在單次作業中擷取它。
在此案例中，使用者端應用程式必須在收到合作夥伴驗證回應之後建立使用者設定檔，並透過單次、一次性的作業擷取該設定檔。
對於任何後續的查詢，必須使用基本設定檔端點來判斷使用者的驗證狀態、存取使用者中繼資料資訊、尋找用於驗證的方法或用於提供身分識別的實體。
如需詳細資訊，請參閱使用合作夥伴流程的單一登入Apple SSO逐步指南(REST API V2)檔案。
11.如果使用者有多個MVPD設定檔，使用者端應用程式該怎麼做？
支援多個設定檔的決策，取決於使用者端應用程式的業務需求。
大部分的使用者將只有一個設定檔。 但是，如果存在多個設定檔（如下所述），使用者端應用程式負責決定設定檔選擇的最佳使用者體驗。
使用者端應用程式可選擇提示使用者選取所需的MVPD設定檔，或自動進行選取，例如從回應中選擇第一個使用者設定檔，或選擇有效期最長的使用者設定檔。
REST API v2支援多個設定檔以適應：
- 使用者可能必須在一般MVPD設定檔與透過單一登入(SSO)取得的設定檔之間進行選擇。
- 使用者無需從其一般MVPD登出，即可獲得暫時存取許可權。
- 具有MVPD訂閱結合直接對消費者(DTC)服務的使用者。
- 有多個MVPD訂閱的使用者。
12.當使用者設定檔過期時，會發生什麼事？
當使用者設定檔到期時，它們不再包含在來自設定檔端點的回應中。
如果Profiles端點傳回空的設定檔對應回應，使用者端應用程式必須建立新的驗證工作階段，並提示使用者重新驗證。
如需詳細資訊，請參閱建立驗證工作階段API檔案。
13.使用者設定檔何時會失效？
使用者設定檔在下列情況下會失效：
- 驗證TTL過期時，如Profiles端點回應中的
notAfter時間戳記所指示。 - 使用者端應用程式變更AP-Device-Identifier標頭值時。
- 當使用者端應用程式更新用於擷取Authorization標頭值的使用者端認證時。
- 當使用者端應用程式撤銷或更新用來取得使用者端認證的軟體陳述式時。
14.使用者端應用程式應何時啟動輪詢機制？
為了確保效率並避免不必要的請求，使用者端應用程式必須在下列條件下啟動輪詢機制：
在主要（熒幕）應用程式內執行的驗證
主要（串流）應用程式應在瀏覽器元件載入工作階段端點要求中redirectUrl引數指定的URL後，於使用者到達最終目的地頁面時開始輪詢。
在次要（熒幕）應用程式內執行的驗證
主要（串流）應用程式應在使用者起始驗證程式後立即開始輪詢 — 在收到工作階段端點回應並向使用者顯示驗證代碼之後。
15.使用者端應用程式何時應停止輪詢機制？
為了確保效率並避免不必要的請求，使用者端應用程式必須在下列條件下停止輪詢機制：
成功的驗證
已成功擷取使用者的設定檔資訊，確認其驗證狀態。 此時，不再需要輪詢。
驗證工作階段與程式碼到期
驗證工作階段和程式碼會過期，如工作階段端點回應中的notAfter時間戳記（例如30分鐘）所指示。 如果發生這種狀況，使用者必須重新啟動驗證程式，而且使用先前驗證代碼的輪詢應該立即停止。
已產生新的驗證碼
如果使用者在主要（熒幕）裝置上要求新的驗證碼，則現有工作階段不再有效，使用先前驗證碼的輪詢應立即停止。
16.使用者端應用程式應用於輪詢機制的呼叫間隔為何？
為了確保效率並避免不必要的請求，使用者端應用程式必須在下列條件下設定輪詢機制頻率：
17.使用者端應用程式可傳送的輪詢要求數目上限是多少？
使用者端應用程式必須遵守Adobe Pass驗證節流機制所定義的目前限制。
使用者端應用程式錯誤處理必須能夠處理429太多要求錯誤碼，這表示使用者端應用程式已超過允許的要求數目上限。
如需詳細資訊，請參閱節流機制檔案。
18.使用者端應用程式如何取得使用者的中繼資料資訊？
使用者端應用程式可以查詢下列端點之一，這些端點能夠傳回使用者中繼資料資訊作為設定檔資訊的一部分：
使用者中繼資料在驗證流程完成後即可使用，因此使用者端應用程式不需要查詢個別端點來擷取使用者中繼資料資訊，因為它已包含在設定檔資訊中。
如需詳細資訊，請參閱下列檔案：
在授權流程期間，某些中繼資料屬性可能會根據MVPD和特定的中繼資料屬性而更新。 因此，使用者端應用程式可能需要再次查詢上述API，以擷取最新的使用者中繼資料。
19.使用者端應用程式應如何管理降級存取？
降級功能可讓使用者端應用程式維持使用者的順暢串流體驗，即使使用者的MVPD驗證或授權服務發生問題亦然。
作為摘要，這可確保MVPD臨時服務中斷的情況下對內容的存取不中斷。
鑑於您的組織打算使用進階降級功能，使用者端應用程式必須處理降級存取流程，以概述REST API v2端點在此類情境下的行為。
如需詳細資訊，請參閱降級存取流程檔案。
20.使用者端應用程式應如何管理暫時存取？
TempPass功能可讓使用者端應用程式提供使用者暫時存取許可權。
作為摘要，這可提供在指定時段內有限的內容存取權或預先定義數量的VOD標題，以吸引使用者。
鑑於您的組織打算使用高級TempPass功能，使用者端應用程式必須處理暫時存取流程，概述了REST API v2端點在此類情況下的行為。
在舊版API中，使用者端應用程式必須登出已透過一般MVPD驗證的使用者，才能提供暫時存取權。
透過REST API v2，使用者端應用程式在授權資料流時，可以順暢地在一般MVPD和TempPass MVPD之間切換，而不需要使用者登出。
如需詳細資訊，請參閱暫時存取流程檔案。
21.使用者端應用程式應如何管理跨裝置單一登入存取？
如果使用者端應用程式提供跨裝置的一致唯一使用者識別碼，REST API v2可啟用跨裝置單一登入。
此識別碼（稱為服務權杖）必須由使用者端應用程式透過實作或整合所選的外部Identity Service而產生。
如需詳細資訊，請參閱使用服務權杖流程的單一登入檔案。
預先授權階段常見問題集
1.預先授權階段的用途為何？
預先授權階段的目的是讓使用者端應用程式能夠在其目錄中呈現使用者有權存取的資源子集。
當使用者第一次開啟使用者端應用程式或導覽至新區段時，「預先授權階段」可以增強使用者體驗。
2.預先授權階段是否為必要階段？
預先授權階段並非強制性，如果使用者端應用程式想要呈現資源目錄而不先根據使用者的許可權進行篩選，則可跳過此階段。
3.什麼是預先授權決定？
預先授權是在字彙表檔案中定義的字詞，而決定字詞也可在字彙表中找到。
預先授權決定儲存有關MVPD預先授權處理查詢結果的資訊，這些資訊可從「決定預先授權」端點擷取。
使用者端應用程式可以使用預先授權決定，呈現電視提供者（資訊性）決定可讓使用者存取的資源子集。
如需詳細資訊，請參閱下列檔案：
4.使用者端應用程式是否應該將預先授權決定快取到永久儲存體中？
使用者端應用程式不需要將預先授權決定儲存在永久儲存體中。 但是，建議將允許決策快取到記憶體中以改善使用者體驗。 這有助於避免對已預先授權的資源之決定預先授權端點進行不必要的呼叫，從而減少延遲並改善效能。
5.使用者端應用程式如何判斷預先授權決定被拒絕的原因？
使用者端應用程式可檢查包含在決定預先授權端點回應中的錯誤碼和訊息，以判斷拒絕預先授權決定的原因。 這些詳細資料可讓您深入瞭解預先授權請求遭拒絕的特定原因，有助於告知使用者體驗或觸發應用程式中的任何必要處理。
如果預先授權決定遭拒，請確定任何針對擷取預先授權決定所實作的重試機制，都不會導致無休止的回圈。
請考慮將重試限制在合理數字，並透過向使用者呈現清楚的意見反應來適當地處理拒絕。
6.為何預先授權決定遺失媒體權杖？
預先授權決定遺失媒體權杖，因為預先授權階段不能用於播放資源，因為這是授權階段的用途。
7.如果預先授權決定已經存在，可以略過「授權階段」嗎？
不適用。
即使預先授權決定可用，也無法跳過授權階段。 預先授權決定僅供參考，不會授予實際的播放許可權。 預先授權階段旨在提供早期指引，但在播放任何內容之前仍需要授權階段。
8.什麼是資源？支援哪些格式？
資源是在字彙表檔案中定義的辭彙。
資源是與MVPD議定的唯一識別碼，並與使用者端應用程式可串流的內容相關聯。
資源唯一識別碼可以有兩種格式：
- 簡單的字串格式，例如管道（品牌）的唯一識別碼。
- 包含其他資訊的媒體RSS (MRSS)格式，例如標題、分級和家長監護中繼資料。
如需詳細資訊，請參閱受保護的資源檔案。
9.使用者端應用程式一次可取得多少資源預先授權決定？
由於MVPD施加的條件，使用者端應用程式可以在單一API要求中取得有限數量資源的預先授權決定，通常最多5個。
您的組織管理員或代表您行事的Adobe Pass驗證代表透過Adobe Pass TVE Dashboard同意MVPD後，可以檢視和變更此最大資源數量。
如需詳細資訊，請參閱TVE儀表板整合使用手冊檔案。
授權階段常見問題集
1.授權階段的用途為何？
授權階段的用途是，在使用者端應用程式透過MVPD驗證其許可權後，提供播放使用者要求的資源的功能。
2.授權階段是否為必要階段？
授權階段是強制性的，如果客戶端應用程式想要播放使用者請求的資源，則無法跳過此階段，因為它需要在釋放資料流之前向MVPD驗證使用者是否有權使用。
3.什麼是授權決定？其有效期為多久？
授權是在字彙表檔案中定義的字詞，而決定字詞也可在字彙表中找到。
授權決定儲存有關MVPD授權程式查詢結果的資訊，這些資訊可從Decisions Authorize端點擷取。
使用者端應用程式可以使用包含媒體權杖的授權決定來播放資源資料流，以備電視提供者（授權）決定允許使用者存取該資料流時使用。
如需詳細資訊，請參閱下列檔案：
授權決定在問題時指定的有限和較短時間範圍內有效，這表示在需要再次查詢MVPD之前，Adobe Pass驗證將快取其的時間量。
這個有限的時間範圍稱為授權(authZ) TTL，可由您的組織管理員或代表您行事的Adobe Pass驗證代表透過Adobe Pass TVE儀表板檢視及變更。
如需詳細資訊，請參閱TVE儀表板整合使用手冊檔案。
4.使用者端應用程式是否應將授權決定快取至永久儲存區？
使用者端應用程式不需要將授權決定儲存在永久儲存體中。
5.使用者端應用程式如何判斷授權決定被拒絕的原因？
使用者端應用程式可以檢查包含在來自Decisions Authorize端點的回應中的錯誤碼和訊息，以判斷拒絕授權決定的原因。 這些詳細資訊可讓您深入瞭解授權請求遭拒的特定原因，有助於告知使用者體驗或觸發應用程式中的任何必要處理。
如果授權決定遭拒，請確定任何針對擷取授權決定所實作的重試機制都不會導致無限回圈。
請考慮將重試限制在合理數字，並透過向使用者呈現清楚的意見反應來適當地處理拒絕。
6.什麼是媒體代號？其有效期為何？
媒體權杖是字彙表檔案中定義的辭彙。
媒體權杖包含以純文字傳送的已簽署字串，可從「決定授權」端點擷取。
如需詳細資訊，請參閱媒體權杖驗證器檔案。
媒體權杖在問題時指定的有限和較短時間範圍內有效，這表示使用者端應用程式必須驗證和使用它之前的時間限制。
使用者端應用程式可以使用媒體權杖來播放資源串流，以備電視提供者（權威）決定允許使用者存取它時使用。
如需詳細資訊，請參閱下列檔案：
7.使用者端應用程式是否應在播放資源資料流之前驗證媒體權杖？
是。
使用者端應用程式必須先驗證媒體權杖，才能開始播放資源資料流。 應該使用媒體權杖驗證器來執行此驗證。 透過驗證傳回token中的serializedToken，使用者端應用程式可協助防止未經授權的存取（例如串流擷取），並確保只有經過適當授權的使用者才能播放內容。
8.使用者端應用程式是否應在播放期間重新整理過期的媒體權杖？
不適用。
當串流正在播放時，使用者端應用程式不需要重新整理過期的媒體Token。 如果媒體權杖在播放期間到期，則應該允許資料流繼續而不中斷。 不過，使用者端在下次嘗試播放資源時，必須要求新的授權決定，並取得新的媒體代號。
9.授權決定中每個時間戳記屬性的用途為何？
授權決定包括數個時間戳記屬性，這些屬性提供有關授權本身及關聯媒體權杖的有效期間的重要內容。 這些時間戳記根據與授權決定或媒體權杖相關，有不同的用途。
決定層級時間戳記
以下時間戳記說明整體授權決定的有效期間：
notBefore權杖層級時間戳記
以下時間戳記說明與授權決定繫結的媒體權杖的有效期：
notBeforenotAfter10.什麼是資源？支援哪些格式？
資源是在字彙表檔案中定義的辭彙。
資源是與MVPD議定的唯一識別碼，並與使用者端應用程式可串流的內容相關聯。
資源唯一識別碼可以有兩種格式：
- 簡單的字串格式，例如管道（品牌）的唯一識別碼。
- 包含其他資訊的媒體RSS (MRSS)格式，例如標題、分級和家長監護中繼資料。
如需詳細資訊，請參閱受保護的資源檔案。
11.使用者端應用程式一次可取得多少資源授權決定？
由於MVPD施加的條件，使用者端應用程式可以在單一API要求中取得有限資源數的授權決定，通常最多1個。
登出階段常見問題集
1.登出階段的用途為何？
登出階段的目的是讓使用者端應用程式能夠應使用者要求，在Adobe Pass驗證中終止使用者的已驗證設定檔。
2.登出階段是否為必要？
登出階段是強制性的，使用者端應用程式必須提供使用者登出的功能。
標題常見問答
1.如何計算Authorization標頭的值？
IMPORTANTBearer存取權杖值，就像之前一樣。Authorization請求標頭包含使用者端應用程式存取受Adobe Pass保護的API所需的Bearer存取權杖。
在註冊階段期間，必須從Adobe Pass驗證取得授權標頭值。
如需詳細資訊，請參閱下列檔案：
2.如何計算AP-Device-Identifier標頭的值？
IMPORTANTAP-Device-Identifier要求標頭包含由使用者端應用程式建立的串流裝置識別碼。
AP-Device-Identifier標題檔案提供主要平台如何計算值的範例，但使用者端應用程式可以根據自己的商業邏輯和需求選擇使用不同的方法。
3.如何計算X-Device-Info標頭的值？
IMPORTANTX-Device-Info要求標頭包含與實際串流裝置相關的使用者端資訊（裝置、連線和應用程式），用來決定MVPD可能強制執行的平台特定規則。
X-Device-Info標題檔案提供主要平台如何計算值的範例，但使用者端應用程式可以根據自己的商業邏輯和需求選擇使用不同的方法。
如果X-Device-Info標頭遺失或包含不正確的值，則請求可能會分類為來自unknown平台。
這可能會導致請求被視為不安全，並受到更嚴格的規則約束，例如較短的驗證TTL。 此外，某些欄位（例如串流裝置connectionIp和connectionPort）是諸如Spectrum的Home Base Authentication之類功能的必要欄位。
即使請求來自代表裝置的伺服器，X-Device-Info標頭值也必須反映實際的串流裝置資訊。
其他常見問答
1.我可以探索REST API V2請求和回應並測試API嗎？
是。
您可以透過我們專屬的Adobe Developer網站探索REST API V2。 Adobe Developer網站可讓您不受限制地存取：
若要與REST API V2互動，您必須包含Authorization標頭，以及透過DCR API取得的Bearer存取權杖。
若要使用DCR API，需要具有REST API V2範圍的軟體陳述式。 如需詳細資訊，請參閱動態使用者端註冊(DCR)常見問題集檔案。
2.我可以使用具備OpenAPI支援的API開發工具來探索REST API V2請求和回應嗎？
是。
您可以從Adobe Developer網站下載DCR API和REST API V2的OpenAPI規格檔案。
若要下載OpenAPI規格檔案，請按一下下載按鈕，將下列檔案儲存到本機電腦：
接著，您可以將這些檔案匯入您偏好的API開發工具，探索REST API V2請求和回應並測試API。
3.我仍可以使用託管於https://sp.auth-staging.adobe.com/apitest/api.html的現有API測試工具嗎？
不適用。
移轉至REST API V2的使用者端應用程式應使用託管於https://developer.adobe.com/adobe-pass/的新測試工具。 Adobe Developer網站可讓您不受限制地存取：
若要與REST API V2互動，您必須包含Authorization標頭，以及透過DCR API取得的Bearer存取權杖。
若要使用DCR API，需要具有REST API V2範圍的軟體陳述式。 如需詳細資訊，請參閱動態使用者端註冊(DCR)常見問題集檔案。
移轉常見問題集
如果您使用的應用程式需要將現有應用程式移轉至REST API V2，請繼續本節內容。
一般移轉常見問題集
1.需要我一次向所有使用者推出移轉至REST API V2的新使用者端應用程式嗎？
不適用。
使用者端應用程式不需要同時推出整合REST API V2的新版本給所有使用者。
到2025年底，Adobe Pass驗證將繼續支援整合REST API V1或SDK的舊版使用者端應用程式。
2.需要我一次在所有API和流程中推出移轉至REST API V2的新使用者端應用程式嗎？
是。
使用者端應用程式需要同時推出跨所有Adobe Pass驗證API和流程整合REST API V2的新版本。
在「第二個熒幕驗證」流程中，使用者端應用程式必須同時針對主要和次要應用程式推出整合REST API V2的新版本。
Adobe Pass驗證將不支援在API和流程之間整合REST API V2和REST API V1/SDK的「混合」實作。
3.更新至移轉至REST API V2的新使用者端應用程式時，是否會保留使用者驗證？
不適用。
在整合REST API V1或SDK的較舊使用者端應用程式版本中取得的使用者驗證將不會保留。
因此，使用者必須在移轉至REST API V2的新使用者端應用程式中重新驗證。
4. REST API V2是否預設啟用增強式錯誤代碼？
是。
移轉至REST API V2的使用者端應用程式預設會自動受益於此功能，提供更詳細且精確的錯誤資訊。
如需詳細資訊，請參閱增強錯誤碼檔案。
5.移轉至REST API V2時，現有的整合是否需要變更設定？
不適用。
移轉至REST API V2的使用者端應用程式不需要變更現有MVPD整合的設定。 此外，他們將繼續對現有服務提供者和MVPD使用相同的識別碼。
此外，Adobe Pass驗證用來與MVPD端點通訊的通訊協定維持不變。
從REST API V1移轉至REST API V2
如果您正在處理需要從REST API V1移轉至REST API V2的應用程式，請繼續此子區段。
註冊階段常見問題集
1.註冊階段需要哪些高階API移轉？
從REST API V1移轉至REST API V2時，註冊階段沒有高層級變更。
使用者端應用程式可以繼續使用相同的流程，透過動態使用者端註冊(DCR)程式針對Adobe Pass驗證進行註冊，並取得存取權杖。
如需詳細資訊，請參閱下列檔案：
設定階段常見問題集
1.設定階段需要哪些高階API移轉？
從REST API V1移轉至REST API V2時，下表呈現需考量的高層級變更：
驗證階段常見問題集
1.驗證階段需要哪些高階API移轉？
從REST API V1移轉至REST API V2時，下表呈現需考量的高層級變更：
如需詳細資訊，請參閱下列檔案：
如需詳細資訊，請參閱下列檔案：
如需詳細資訊，請參閱下列檔案：
如需詳細資訊，請參閱下列檔案：
GET
/api/v2/{serviceProvider}/profiles
GET
/api/v2/{serviceProvider}/profiles/{mvpd}
GET
/api/v2/{serviceProvider}/profiles/code/{code}
使用者端應用程式可一次將這些API的回應用於多個用途：
- 檢查使用者驗證狀態
- 擷取使用者設定檔
- 擷取使用者中繼資料資訊
如需詳細資訊，請參閱下列檔案：
GET
/api/v2/{serviceProvider}/profiles
GET
/api/v2/{serviceProvider}/profiles/{mvpd}
GET
/api/v2/{serviceProvider}/profiles/code/{code}
使用者端應用程式可一次將這些API的回應用於多個用途：
- 檢查使用者驗證狀態
- 擷取使用者設定檔
- 擷取使用者中繼資料資訊
如需詳細資訊，請參閱下列檔案：
GET
/api/v2/{serviceProvider}/profiles
GET
/api/v2/{serviceProvider}/profiles/{mvpd}
GET
/api/v2/{serviceProvider}/profiles/code/{code}
使用者端應用程式可一次將這些API的回應用於多個用途：
- 檢查使用者驗證狀態
- 擷取使用者設定檔
- 擷取使用者中繼資料資訊
如需詳細資訊，請參閱下列檔案：
預先授權階段常見問題集
1.預先授權階段需要哪些高階API移轉？
從REST API V1移轉至REST API V2時，下表呈現需考量的高層級變更：
授權階段常見問題集
1.授權階段需要哪些高階API移轉？
從REST API V1移轉至REST API V2時，下表呈現需考量的高層級變更：
登出階段常見問題集
1.登出階段需要哪些高階API移轉？
從REST API V1移轉至REST API V2時，下表呈現需考量的高層級變更：
從SDK移轉至REST API V2
如果您正在處理需要從SDK移轉至REST API V2的應用程式，請繼續此子區段。
註冊階段常見問題集
1.註冊階段需要哪些高階API移轉？
從SDK移轉至REST API V2時，下表呈現需考量的高層級變更：
AccessEnabler JavaScript SDK
如需詳細資訊，請參閱下列檔案：
AccessEnabler iOS/tvOS SDK
如需詳細資訊，請參閱下列檔案：
AccessEnabler Android SDK
如需詳細資訊，請參閱下列檔案：
AccessEnabler FireOS SDK
如需詳細資訊，請參閱下列檔案：
設定階段常見問題集
1.設定階段需要哪些高階API移轉？
從SDK移轉至REST API V2時，下表呈現需考量的高層級變更：
AccessEnabler JavaScript SDK
AccessEnabler iOS/tvOS SDK
AccessEnabler Android SDK
AccessEnabler FireOS SDK
驗證階段常見問題集
1.驗證階段需要哪些高階API移轉？
從SDK移轉至REST API V2時，下表呈現需考量的高層級變更：
AccessEnabler JavaScript SDK
如需詳細資訊，請參閱下列檔案：
GET
/api/v2/{serviceProvider}/profiles
GET
/api/v2/{serviceProvider}/profiles/{mvpd}
GET
/api/v2/{serviceProvider}/profiles/code/{code}
使用者端應用程式可一次將這些API的回應用於多個用途：
- 檢查使用者驗證狀態
- 擷取使用者設定檔
- 擷取使用者中繼資料資訊
如需詳細資訊，請參閱下列檔案：
GET
/api/v2/{serviceProvider}/profiles
GET
/api/v2/{serviceProvider}/profiles/{mvpd}
GET
/api/v2/{serviceProvider}/profiles/code/{code}
使用者端應用程式可一次將這些API的回應用於多個用途：
- 檢查使用者驗證狀態
- 擷取使用者設定檔
- 擷取使用者中繼資料資訊
如需詳細資訊，請參閱下列檔案：
AccessEnabler iOS SDK
如需詳細資訊，請參閱下列檔案：
GET
/api/v2/{serviceProvider}/profiles
GET
/api/v2/{serviceProvider}/profiles/{mvpd}
GET
/api/v2/{serviceProvider}/profiles/code/{code}
使用者端應用程式可一次將這些API的回應用於多個用途：
- 檢查使用者驗證狀態
- 擷取使用者設定檔
- 擷取使用者中繼資料資訊
如需詳細資訊，請參閱下列檔案：
GET
/api/v2/{serviceProvider}/profiles
GET
/api/v2/{serviceProvider}/profiles/{mvpd}
GET
/api/v2/{serviceProvider}/profiles/code/{code}
使用者端應用程式可一次將這些API的回應用於多個用途：
- 檢查使用者驗證狀態
- 擷取使用者設定檔
- 擷取使用者中繼資料資訊
如需詳細資訊，請參閱下列檔案：
AccessEnabler tvOS SDK
如需詳細資訊，請參閱下列檔案：
如需詳細資訊，請參閱下列檔案：
如需詳細資訊，請參閱下列檔案：
如需詳細資訊，請參閱下列檔案：
GET
/api/v2/{serviceProvider}/profiles
GET
/api/v2/{serviceProvider}/profiles/{mvpd}
GET
/api/v2/{serviceProvider}/profiles/code/{code}
使用者端應用程式可一次將這些API的回應用於多個用途：
- 檢查使用者驗證狀態
- 擷取使用者設定檔
- 擷取使用者中繼資料資訊
如需詳細資訊，請參閱下列檔案：
GET
/api/v2/{serviceProvider}/profiles
GET
/api/v2/{serviceProvider}/profiles/{mvpd}
GET
/api/v2/{serviceProvider}/profiles/code/{code}
使用者端應用程式可一次將這些API的回應用於多個用途：
- 檢查使用者驗證狀態
- 擷取使用者設定檔
- 擷取使用者中繼資料資訊
如需詳細資訊，請參閱下列檔案：
AccessEnabler Android SDK
如需詳細資訊，請參閱下列檔案：
GET
/api/v2/{serviceProvider}/profiles
GET
/api/v2/{serviceProvider}/profiles/{mvpd}
GET
/api/v2/{serviceProvider}/profiles/code/{code}
使用者端應用程式可一次將這些API的回應用於多個用途：
- 檢查使用者驗證狀態
- 擷取使用者設定檔
- 擷取使用者中繼資料資訊
如需詳細資訊，請參閱下列檔案：
GET
/api/v2/{serviceProvider}/profiles
GET
/api/v2/{serviceProvider}/profiles/{mvpd}
GET
/api/v2/{serviceProvider}/profiles/code/{code}
使用者端應用程式可一次將這些API的回應用於多個用途：
- 檢查使用者驗證狀態
- 擷取使用者設定檔
- 擷取使用者中繼資料資訊
如需詳細資訊，請參閱下列檔案：
AccessEnabler FireOS SDK
如需詳細資訊，請參閱下列檔案：
如需詳細資訊，請參閱下列檔案：
如需詳細資訊，請參閱下列檔案：
如需詳細資訊，請參閱下列檔案：
GET
/api/v2/{serviceProvider}/profiles
GET
/api/v2/{serviceProvider}/profiles/{mvpd}
GET
/api/v2/{serviceProvider}/profiles/code/{code}
使用者端應用程式可一次將這些API的回應用於多個用途：
- 檢查使用者驗證狀態
- 擷取使用者設定檔
- 擷取使用者中繼資料資訊
如需詳細資訊，請參閱下列檔案：
GET
/api/v2/{serviceProvider}/profiles
GET
/api/v2/{serviceProvider}/profiles/{mvpd}
GET
/api/v2/{serviceProvider}/profiles/code/{code}
使用者端應用程式可一次將這些API的回應用於多個用途：
- 檢查使用者驗證狀態
- 擷取使用者設定檔
- 擷取使用者中繼資料資訊
如需詳細資訊，請參閱下列檔案：
預先授權階段常見問題集
1.預先授權階段需要哪些高階API移轉？
從SDK移轉至REST API V2時，下表呈現需考量的高層級變更：
AccessEnabler JavaScript SDK
AccessEnabler iOS/tvOS SDK
AccessEnabler Android SDK
如需詳細資訊，請參閱下列檔案：
授權階段常見問題集
1.授權階段需要哪些高階API移轉？
從SDK移轉至REST API V2時，下表呈現需考量的高層級變更：
AccessEnabler JavaScript SDK
AccessEnabler iOS/tvOS SDK
AccessEnabler Android SDK
AccessEnabler FireOS SDK
登出階段常見問題集
1.登出階段需要哪些高階API移轉？
從SDK移轉至REST API V2時，下表呈現需考量的高層級變更：