---
title: "How License Issuance Works"
description: "Explains the token and token proxy license issuance models, how each flow works, and how license validity periods behave on client devices."
---
> For the complete documentation index, see [llms.txt](https://docs.doverunner.com/llms.txt).

To play packaged content, a client device needs a DRM license. DoveRunner issues licenses in two ways: **token** and **token proxy**. This page explains how each works, how to choose between them, and how license validity periods behave. The token itself is specified in the [License Token Guide](https://docs.doverunner.com/content-security/multi-drm/license/license-token/).

## Choosing an integration type

|<div style="width:80px">Integration type</div>| Description | Pros | Cons |
| --- | --- | --- | --- |
|**Token**|The user authentication is done between your back-end system and client app before generating a license token.|Better performance on license issuance because the process is simpler than callback type.|More implementation work needed in client app. You need to manage the generated token securely on your own.|
| **Token proxy** |A proxy server of the customer's backend relays the license request/response between the client application and the DoveRunner license server. | Additional security can be implemented at the customer's discretion during the license issuance process. Functions such as limiting the number of devices can be implemented through custom type DRM license data. | Higher difficulty because of many parts that the customer needs to implement. |

> The old callback type integration method is deprecated because delays or errors may occur depending on the situation of the customer's system. We recommend the use of token method in general, and the token proxy can be used to implement DRM integration at the customer's discretion, such as additional security processing.

## Token License Issuance Flow

```mermaid
sequenceDiagram
    box End User
    participant A as End user (Client)
    end
    box Content Service
    participant B as Content Service Site
    end
    box DoveRunner
    participant C as DoveRunner Cloud Server
    end
    A ->> B: Login to service site
    B -->> B: Authenticate user
    B ->> A: Send available content list
    A -->> A: Select content to play
    opt License Token Integration
    A ->> B: Request token
    B -->> B: Authorize and create license token
    B ->> A: Send license token
    end
    A ->> C: Request DRM license with token
    C -->> C: Verify token
    C ->> A: Issue DRM license
    A -->> A: Playback content
```

(1) Request a token to service site

- Client requests its service site for a token to playback DRM content.

(2) Token generation (see the [specification](https://docs.doverunner.com/content-security/multi-drm/license/license-token/#token-json-format))

- The service site checks the request received from the client and generates a token if the user has permission to use the content.
- Token includes information such as Content ID, user ID, timestamp, and license rules.

(3) Token transfer

- The service site returns the generated token to the client as a response.
> The creation of the token and the request / response function are not provided by DoveRunner. The service site should implement these functions according to the [License Token Guide](https://docs.doverunner.com/content-security/multi-drm/license/license-token/).

(4) Request for a license

- The client places the received token(base64 string) in pallycon-customdata-v2 and requests license to DoveRunner cloud server.

(5) Issuing a license

- DoveRunner cloud server validates the token and issues a license according to the rules in the token.

## Token Proxy Type License Issuance Flow

Token-based license issuance can also be handled through a proxy server at the service site, as shown below.

```mermaid
sequenceDiagram
    box End User
    participant A as End user(Client)
    end
    box Content Service
    participant B as Content Service Site
    end
    box DoveRunner
    participant C as DoveRunner Cloud Server
    end
    A ->> B: Login to service site
    B -->> B: Authenticate user
    B ->> A: Send available content list
    A -->> A: Select content to play
    A ->> B: DRM license request (challenge + auth data)
    opt Token proxy integration
    B -->> B: Authorize user and create token
    B ->> C: Request license with challenge and token
    C -->> C: Verify token
    C ->> B: Issue DRM license
    end
    B ->> A: Response DRM license
    A -->> A: Playback content
```

(1) Request DRM license to proxy server

* A client requests a DRM license to a proxy server of the service site for DRM content playback.
* The client calls the URL of the proxy server instead of DoveRunner license server URL by DRM LA_URL configuration. Any data for the user authentication may be sent to the proxy via custom header, cookie, or URL parameter of the license request. (using customer's own auth data specification)
* License request data (body) sent to the proxy server include challenge data generated by the client's DRM module.

(2) Authorize the user and create token

* Service site checks if the user has a right for the content using the auth data sent to the proxy server.
* The proxy server generates a license token with DRM license rules for the service's business model and security policy.
* If you want to receive a custom type license response to implement additional functions, such as limiting the number of devices, set the corresponding option (response_format) in the token data.

(3) Request DRM license to DoveRunner server

* The proxy server requests a DRM license to DoveRunner license server with the generated token and the license challenge data sent from the client.
* DoveRunner server validates the token and issues DRM license using the challenge data.

(4) Response license and playback content

* The proxy server delivers the DRM license data issued by the DoveRunner license server to the client.
* If the custom type response option is set for the token, the proxy should parse the JSON format custom license response and deliver the original license response to the client.
* The client player starts playing content using the delivered DRM license.

## License validity

How long a license stays valid, and what happens when it expires, depends on the scenario and on the client. The fields that control it are listed under [playback_policy](https://docs.doverunner.com/content-security/multi-drm/license/license-token/#playback_policy) in the License Token Guide.

### Notes on various durations of a DRM license

If the license expires during content playback, whether or not to stop playback is divided as follows according to the client environment and the corresponding DRM standard.
- `Hard expiry`: When the license expires, content decryption stops immediately and playback stops.
- `Soft expiry`: During content playback, playback continues even if the license expires. After the content has been played to the last point or has been stopped by the user, playback cannot be resumed with that license.

Please note that different methods may be applied to the same playback policy depending on the client device and OS version, so whether or not to stop playback when the license expires during content playback may vary depending on the client environment.

### License validity period in streaming scenario

In a streaming scenario, user rights are checked and new licenses are issued every time playback starts even for the same content. Therefore, for video on demand (VOD) stream with a finite length of content or live content that is temporarily serviced for a specific event, the validity period generally does not need to be apply to the DRM license.

Even in the case of 24/7 linear channels where the length of the content is not fixed, in most cases, periodic authorization check is performed through the key rotation function instead of setting the validity period in the license.

Unless there are special requirements, it is recommended to apply the streaming license's `playback policy` with  default (unlimited) duration as follows.

```json
    "playback_policy": {
        "persistent": false
    }
```

### License validity period in offline scenario

`Offline rental` is a scenario in which content and DRM license are downloaded in an online environment and then the content is played with the persistent license stored in the device in an offline environment.

In that scenario, there are usually two validity periods:

- `rental duration`: The validity period from the time the license is downloaded to the first start of playback (downloaded content can be stored for 30 days, for example) Content that has not been played even once during that period cannot be played because of license expiration.
- `playback duration`: License validity period from the time of initial playback (playable period, e.g. 24 hours) Content cannot be played after the `playback duration` period after the first playback starts, even if it is within the `rental duration`.

When the content and license are downloaded, only the countdown for the `rental duration` starts, and from the first playback of the downloaded content, the `rental duration` value is no longer used and only the `playback duration` is applied.

The `playback policy` for requesting a license for offline rental with the validity period example above (30 days storage, 24 hours playback) is as follows.

```json
    "playback_policy": {
        "persistent": true,
        "rental_duration": 2592000,
        "playback_duration": 86400
    }
```