Connect your licensed applications and devices

For implementing licensing for your software application with 10Duke Scale, your application must be able to connect to 10Duke Scale to verify that the license consumer, such as a user or a device, has access to a valid license for using the application.

Your application must be able to handle the authorization for sending requests to 10Duke Scale APIs, and in the case of identity-based licensing, also to authenticate the user or device that is trying to access the license. For the latter, your application must be able to run an OpenID Connect (OIDC)/OAuth authentication flow with an external identity provider, which then provides your application with an ID token.

This allows your application to send authorized requests to handle the consumption of the license to get a license token, and then enforce the license on the use of the application and its features. Depending on your business case and your type of application, the application may need to, for example, query what licenses the license consumer has access to, query what licenses they’re currently using, enforce the existence and availability of the license in the application, and report to 10Duke Scale on the quantity consumed from the license.

When connecting your application to the 10Duke Scale APIs, it’s essential to first understand what type of an application you’re integrating.

Let’s first take a look at a key security aspect related to your application—whether you’re implementing a confidential or a public application—and then dive deeper into how to integrate different types of applications.

Confidential vs. public applications

Whether your application is confidential or public affects the choices you can and should make for API authorization and OIDC/OAuth authentication.

So, what is a confidential application and a public application?

A confidential application is an application that you, the vendor, fully control and trust. If proper design and best practices are followed, the end user doesn’t have access to the process that the application executes in. This means this type of an application is able to securely store secrets and credentials.

A good example of a confidential application is a server-side web or software-as-a-service (SaaS) application that only you, the vendor, have access to.
With a public application, the end user has access to the running process, storage, and network. This means the application is unable to store secrets and credentials without the risk of exposing them to the end user, and a connecting system or an API cannot trust this type of an application.

Examples of public applications are desktop, mobile, and browser-based applications, as well as server applications that are installed in customer premises.

Both confidential and public applications can use ID token and license key based API authorization to connect to the 10Duke Scale License Checkout API for license consumption.

However, API authorization using a 10Duke Scale JWT token is only possible with a confidential application, which is able to securely store the private key that is needed for signing the API authorization tokens. This authorization method allows the application to also connect to the 10Duke Scale License Management API, if your business case requires it.

In addition, when implementing authentication with an external identity provider, only a confidential application can use those OIDC/OAuth authentication flows that require the ability to securely store secrets.

See more about which authorization method to choose for your application.

Application types

Applications come in many shapes and forms, from locally installed desktop and mobile applications to online SaaS services.

Each application type has a slightly different comfort zone for implementing the shared need of enforcing the existence of valid licenses before it allows an end user to access features and functions.

The type of your application (or your combination of applications) also to some extent affects what type of a license model you should apply to licenses.

The following sections provide information on the implementation options typically used with different types of applications. It’s good to keep in mind that other alternatives and variations are possible, and the most feasible implementation is usually determined by the particular type of application you’re integrating and your business requirements.

Desktop and mobile applications

Desktop and mobile applications are public applications, which means it’s common to implement API authorization with an ID token or a license key.

When implementing an OIDC/OAuth flow for authenticating the user or device with an external identity provider, a desktop or mobile application would typically use the authorization code grant flow with the Proof Key for Code Exchange (PKCE) extension. PKCE provides a secure way to use the authorization code grant flow for a public application that cannot store a client secret.

For license use, a desktop or mobile application is commonly able to communicate the start and end of a consumption of a license. This means it’s possible to implement a formal checkout flow to actually consume quantity from the license (seats, use count, or use time).

Desktop and mobile applications also often run on a computer or device that is dedicated to serve a single user. This allows anchoring the license checkout to that specific computer or device if your license model requires this.

Web and SaaS applications

Web and SaaS applications are typically confidential applications that run in your (the vendor’s) own infrastructure and nobody else is able to access the installation. As an exception, if you’re providing a web application to customers as their own local installation, it’s best practice to handle it as a public application.

Even though a confidential application allows using any of the API authorization methods available, web and SaaS applications are commonly implemented with identity-based authorization with an ID token. This is because it’s typically difficult to identify with sufficient certainty the device on which the license is being consumed, and users also typically expect to be able to use a web or SaaS application from any device. The basis for license use is then to first identify the user, and next identify which licenses that user has access to.

When implementing an OIDC/OAuth flow for authenticating the user with an external identity provider, a web or SaaS application would typically use the authorization code grant flow, because it’s able to securely store the client secret needed by the flow.

For license use, a web or SaaS application can be implemented to either use a formal checkout flow or to rely on feature flags.

The choice depends on your business case: does your application need to formally track and consume quantity from a license, or is it sufficient for the application to know that a valid license exists? An integration using feature flags is typically easier to implement, and with a web or SaaS application, there’s also often no need to track concurrent use (of seats) of a license, which would only be possible through a formal checkout flow.

In a feature flag implementation, your application first queries the combined information of all licenses the user has access to, returned as a breakdown of products and features. The application then uses that information to allow or deny access to the application’s parts and features.

Device (embedded) applications

Device applications, also often called embedded applications, are typically public applications. They’re similar to desktop and mobile applications, but there are typically some significant differences in production and delivery, and those also affect the choices on how to integrate your device application to 10Duke Scale.

A common characteristic of device applications is that they’re delivered as part of a larger solution of multiple applications, where the device application is controlled and managed using, for example, a desktop or mobile application. Another common case is a device that provides a user interface for controlling the device application.

There are a lot of different options and combinations in how the integration of a device application could be handled, and various aspects that you should consider in the planning. Let’s take a look at a few key things to help you evaluate your options.

Common device implementations

A common implementation is that the license creation and the implementation of authorization and authentication happen already in the manufacturing phase. The information needed for consuming the license is embedded in the device application during manufacturing: either a license key (generated together with the license) or a license token.

Another typical implementation is to allow the end user to take the device into use through a separate management application. The management application provides the implementation for the end user, for example, to enter a license key, or to log in (in identity-based licensing). The solution could then rely on either the management application just handing over the license key or ID token to the device application to do the license checkout, or the management application handling the checkout and passing the license token to the device application.

Who handles the checkout?

Note the key differentiator in the implementations described above:

Will your device application be in possession of just the license token?

This means the initial checkout has already been done on behalf of the device application. Depending on your solution, your manufacturing process could handle the checkout to allow embedding the token, or the checkout could be handled by a management application.

At minimum, your device application needs to verify and handle the license token provided to it in order to enforce the license.

If the device application is able to connect to the internet, it could potentially handle the heartbeat and release (if needed), but these could also be handled by a management application if your solution uses one.
Will your device application be in possession of the information needed to get the license token (a license key or an ID token)?

This means the device application must be able to handle the whole license consumption lifecycle: use the license key or ID token to check out the license and get a license token, and handle the heartbeat and release (if needed).

UI or no UI?

Whether your device has a user interface also affects your implementation decisions.

If your device has a UI and there’s no management application involved, the device application itself could also provide the implementation for a user login to get an ID token.
With a non-UI device, using a license key is likely a better option. If embedding a license key is not possible, another option could be to allow the end user to attach a storage device (such as a USB flash drive) to the device for transferring the license key.