Posted by Chris Needham on , last updated

At BBC R&D, we have been working on user authentication on media devices for some time now, starting with RadioTAG, and then authentication on connected TV. Most recently, over the last year we've been working in collaboration with the EBU, other European public service and commercial broadcasters, and device manufacturers, to develop the Cross Platform Authentication (CPA) protocol, the first version of which was recently published by the EBU.

CPA provides a way of securely associating an internet-connected media device with an online user account, to enable delivery of personalised services to the device, for example, media recommendations, bookmarking, and pause/resume of media playback between devices. In its first version, CPA focuses on hybrid (i.e., broadcast and internet) radios, but could also be applied to connected TVs or set-top boxes.

The protocol is based on OAuth 2.0 but adapted to the characteristics of media devices, and to the needs of broadcasters, as described below. The authentication flow is based on the draft OAuth 2.0 device profile.

The following diagram shows the different entities that participate in the CPA protocol. These are the client, service provider, authorization provider, and (indirectly) the identity provider. The goal of CPA is to grant the client permission to make authenticated API calls to the service provider on behalf of an end user. The authorization provider manages client identities, and the link between the client and the end user's identity (which is obtained from the identity provider).

CPA entities

Device characteristics

Radios typically have small display screens, e.g., a small colour LCD or a two-line text-only display. They also do not have a convenient way for users to input information such as a username or password.

One of our aims in designing CPA was to impose as few extra requirements onto devices as possible, to be as compatible as possible with existing devices. For example, CPA does not require a remote control with a keyboard, or a smartphone with a camera, as in QR code based solutions.

Single sign-on

Another important requirement that CPA addresses is single sign-on. This allows a user to pair their device with a broadcaster's service only once, e.g., for one radio station, then they can remain signed in when listening to any radio station from that broadcaster. Multiple broadcasters can also share a common authorization service, which allows single sign-on across these broadcasters' services, while keeping the user data held by these services separate from each other.

CPA single sign-on group

CPA in practice

Recently, we worked with BBC Playlister and Kite to integrate CPA and RadioTAG, allowing listeners to add tracks to their playlists directly from their radios. Although this is currently only possible on certain prototype radios, we're talking to manufacturers about adding it to their products and are hoping to see it on the shelves in due course.

The video below shows how the sign-in process works from the user's perspective.

Cross Platform Authentication: RadioTAG and BBC Playlister

The user presses a button on the radio to add the track they're listening to to their playlist. The radio makes a call to Playlister's web API, and receives a HTTP 401 response indicating that authentication is required. This response includes the URL of the authorization provider the radio should use to authenticate.

The radio then calls the authorization provider, firstly to register as a client, then to associate the client with a user account.

In response the radio receives a URL that the user should visit, and a short security code for them to type in, which the radio displays to the user.

Radio showing the security code

On their PC or smartphone, the user visits this URL and the website asks them to sign in and input the security code. This step associates the radio with the signed in user.

User inputs the security code

By periodically polling the authorization provider, the device automatically detects that the security code has been input correctly, and is given an access token that allows it to store data on behalf of the user. The device can then use this token to add the track to the user's playlist.

The user's playlist

For more information

If you want more information about CPA, or have comments or questions about the specification, please contact us via the EBU working group.

The specification itself is available from the EBU website and there are open-source software reference implementations of the client and servers, available on our project page.


We'd like to thank Michael Barroco of the EBU for coordinating the CPA working group, and all the participants in the group for their input and contribution to the development of the protocol.