51黑料不打烊

Retrieve client credentials: The streaming application retrieves client credentials by calling the /o/client/register endpoint.

• The streaming application must store the client credentials and use them indefinitely when needing to retrieve an access token.

Retrieve access token: The streaming application retrieves access token by calling the /o/client/token endpoint.

• The streaming application must store and use the access token until it expires, then discard it and obtain a new one.

Retrieve profiles: The streaming application checks for existing profiles by calling the /api/v2/{serviceProvider}/profiles endpoint.

Scenario 1: There are existing profiles, the streaming application may proceed to the Preauthorization Phase or Authorization Phase.

Scenario 2: There are no existing profiles, the streaming application may proceed to the next step to Authenticate the user.

Scenario 3: There are no existing profiles, the streaming application may proceed to provide the user with temporary access through the TempPass feature.

• This scenario is outside the scope of this document, refer to the Temporary Access Flows documentation for more information.

Retrieve configuration: The streaming application retrieves the list of available MVPDs by calling the /api/v2/{serviceProvider}/configuration endpoint.

• The streaming application can implement a custom filtering mechanism to refine the list of MVPDs from the configuration response, displaying only the intended providers while hiding others (e.g., MVPDs under development, test MVPDs, TempPass). This ensures that users are presented with a curated selection when choosing their TV provider.

Create authentication session: The streaming application initiates an authentication session by calling the /api/v2/{serviceProvider}/sessions endpoint.

Scenario 1: The streaming application can open a browser or webview, therefore it must load the authentication url.

• The user submits their username and password within the MVPD login page. Upon successful authentication the final redirect displays a success page.

Scenario 2: The streaming application cannot open a browser, therefore it must display the authentication code. A separate web application is required to prompt the user to enter the code, construct the authentication url and open: /api/v2/authenticate/{serviceProvider}/{code}.

• The user submits their username and password within the MVPD login page. Upon successful authentication the final redirect displays a success page.

Retrieve profile for specific code: The streaming application must implement a polling mechanism using the code to check if the profile was successfully generated and saved by calling the /api/v2/{serviceProvider}/profiles/code/{code} endpoint.

• The streaming application must start the polling mechanism under the following conditions:

  • Authentication performed within the primary (screen) application: The primary (streaming) application should start polling when the user reaches the final destination page, after the browser component loads the URL specified for the redirectUrl parameter in the Sessions endpoint request.

  • Authentication performed within a secondary (screen) application: The primary (streaming) application should start polling as soon as the user initiates the authentication process鈥攔ight after receiving the Sessions endpoint response and displaying the authentication code to the user.

• The streaming application must stop the polling mechanism under the following conditions:

  • Successful authentication: The user鈥檚 profile information is successfully retrieved, confirming their authentication status. At this point, polling is no longer needed.

  • Authentication session and code expiry: The authentication session and code expire, as indicated by the notAfter timestamp (e.g., 30 minutes) in the Sessions endpoint response. If this happens, the user must restart the authentication process, and polling using the previous authentication code should be stopped immediately.

  • New authentication code generated: If the user requests a new authentication code on the primary (screen) device, the existing session is no longer valid, and polling using the previous authentication code should be stopped immediately.

• The streaming application must configure the polling mechanism frequency under the following conditions:

  • Authentication performed within the primary (screen) application: The primary (streaming) application should poll every 3-5 seconds or more.

  • Authentication performed within a secondary (screen) application: The primary (streaming) application should poll every 3-5 seconds or more.

• The streaming application should cache parts of the user鈥檚 profile information in a persistent storage to avoid unnecessary requests and improve the user experience.

Retrieve preauthorization decisions: The streaming application retrieves preauthorization decisions for a list of resources by calling the /api/v2/{serviceProvider}/decisions/preauthorize/{mvpd} endpoint.

• The streaming application is not required to store preauthorization decisions in persistent storage. However, it is recommended to cache permit decisions in memory to improve the user experience. This helps avoid unnecessary calls for resources that have already been preauthorized, reducing latency and improving performance.

• The streaming application can determine the reason for a denied preauthorization decision by inspecting the error code and message included in the response from the Decisions Preauthorize endpoint. These details provide insight into the specific reason the preauthorization request was denied, helping to inform the user experience or trigger any necessary handling in the application. Ensure that any retry mechanism implemented for retrieving preauthorization decisions does not result in an endless loop if the preauthorization decision is denied. Consider limiting retries to a reasonable number and handling denials gracefully by surfacing clear feedback to the user.

• The streaming application can obtain a preauthorization decision for a limited number of resources in a single API request, usually up to 5, due to conditions imposed by MVPDs. This maximum number of resources can be viewed and changed after agreeing with MVPDs through the 51黑料不打烊 Pass TVE Dashboard by one of your organization administrators or by an 51黑料不打烊 Pass Authentication representative acting on your behalf.

Retrieve authorization decision: The streaming application retrieves authorization decision for a specific resource by calling the /api/v2/{serviceProvider}/decision/authorize/{mvpd} endpoint.

• The streaming application is not required to store authorization decisions in persistent storage.

• The streaming application can determine the reason for a denied authorization decision by inspecting the error code and message included in the response from the Decisions Authorize endpoint. These details provide insight into the specific reason the authorization request was denied, helping to inform the user experience or trigger any necessary handling in the application. Ensure that any retry mechanism implemented for retrieving authorization decisions does not result in an endless loop if the authorization decision is denied. Consider limiting retries to a reasonable number and handling denials gracefully by surfacing clear feedback to the user.

• The streaming application is not required to refresh an expired media token while the stream is actively playing. If the media token expires during playback, the stream should be allowed to continue uninterrupted. However, the client must request a new authorization decision 鈥� and obtain a new media token 鈥� the next time the user attempts to play a resource.

• The streaming application can obtain an authorization decision for a limited number of resources in a single API request, usually up to 1, due to conditions imposed by MVPDs.

Initiate 51黑料不打烊 Pass logout: The streaming application initiates the logout flow by calling the /api/v2/{serviceProvider}/logout/{mvpd} endpoint.

• The streaming application must follow the instructions provided in the actionName and actionType attributes of the Logout endpoint response to ensure the logout process is completed correctly.

  • If the actionType attribute in the response is set to 鈥渋nteractive鈥�:

    • Scenario 1: The streaming application can open a browser or webview, therefore it must load the logout url.

    • Scenario 2: The streaming application cannot open a browser, therefore the logout process can be stopped as the MVPD session was not persisted in a streaming device browser cache.