Connected Devices

Connected Devices apps communicate directly with Adobe Pass Authentication through the REST APIs to perform configuration, registration, authentication status checks and authorization flows, while a second screen (browser) app is required for the authentication flow. As such, native SDKs are not used.

Other Architectures

In addition to the two primary REST API based architectures, Server-to-server and Direct client solutions for smart devices, there are other architectures. Primary among them is the SDK architecture, which uses a client component called the Access Enabler that Adobe Pass Authentication provides to Programmers. The app uses Access Enabler APIs to handle startup, authentication, authorization, and logout. All communication between the Programmer’s app and the Adobe Pass Authentication servers occurs through the Access Enabler. A different flavor of Access Enabler is available for the following platforms: JavaScript, iOS, tvOS, Android and FireTV.

Although it is possible to use the REST API directly on client platforms that support native SDKs outside of a Server-to-Server solution, this approach is not recommended.

REST API Pros and Cons

The Adobe Pass Authentication REST API was created to provide a TV Everywhere (TVE) solution for devices that do not have web browsing capabilities or persistent storage. The REST API provides support for all authentication and authorization flows, but because it lacks a native SDK component. The SDKs provided and maintained by Adobe Pass Authentication come with out-of-the box functionalities that implement business rules which in case of the REST API have to be implemented and maintained by the Programmers. In the Programmer Responsibilities table below we describe the limitations of the current REST API that need to be addressed by Programmers.