Connect your licensed applications and devices

The use of an application must be authorized by having a valid license and by verifying the corresponding license tokens in the application. See more information on license consumption and how to implement it.

Application types

Applications come in many shapes and forms, from desktop and mobile applications to online software-as-a-service (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 a user to access features and functions.

Example interactions:

  • The application user asks what licenses they can use.

  • The application and its user ask what licenses the user is currently using.

  • The application enforces the existence and availability of a license.

Desktop and mobile applications

These types of applications are commonly able to communicate the start and end of using a license. This means it’s possible to implement a formal checkout-heartbeat-release flow.

Applications of this type often also run on a computer or device dedicated to serve a single user. If needed, the license checkout can be anchored to that specific computer or device.

Web and SaaS applications

These types of applications are commonly easier to integrate by relying on the existence of a valid license rather than implementing a checkout-release flow. This is because most web-based and SaaS apps don’t reserve a device per user.

Using one of these approaches may often work better in web-based apps. Query the licensing API to:

  • Check what licenses the user has access to.

  • Ask for license information as feature flags.

  • Use the above information to allow or deny access to the application or parts of it.

Confidential applications

A confidential application is an application that you as the vendor fully control and trust. If proper design and best practices are followed, this type of application is able to securely store secrets and credentials.

This means that the end user doesn’t have access to the process that the application executes in. A good example of this is a server-side application that only you have access to.

Public applications

Desktop, mobile, Javascript, and browser-based applications are examples of public applications.

Public applications are not able to store secrets and credentials without the risk of exposing them to the end user, because the end user has access to the running process, storage, and network. This means a system or an API cannot trust this type of an application.

Using an external identity provider for identity-based licensing

Identity-based licensing is supported by using a standards-based OpenID Connect (OIDC) identity provider.

The application is responsible for handling the authentication process with the identity provider to obtain an ID token, which enables it to make authorized calls to the 10Duke Scale License Checkout API.

The license consumer field called “connected identity ID” is used to store the user ID owned by the identity provider. Set the value of this field to the OIDC user ID to support identity-based licensing and ID token authorization.

See how to define the connected identity ID for a license consumer, and how to authorize API requests with an ID token.

Contents