Licensing plugins, add-ons, and extensions

Plugins, add-ons, and extensions add optional capabilities to a host application, such as modules in a design suite, extensions in an IDE, or effects in an audio workstation. This article refers to them collectively as add-ons. When licensing them, the goal is to control which add-ons a customer can use independently of the base product, and optionally to meter their usage. In 10Duke Enterprise, you model each add-on as a licensed item that the application checks at runtime, whether the add-on ships with the product or is sold on its own.

10Duke Enterprise licensing solutions for plugins, add-ons, and extensions

In the most common setup, add-ons run inside a host application and don’t authenticate separately. The host application authenticates as it normally would—an interactive user login for a desktop, mobile, or web application, or the client credentials grant flow for a backend service—and the same access token is reused to check the add-ons. This works when the host and its add-ons resolve to the same 10Duke Enterprise identity domain, which is typically the case when a single vendor licenses both the host and the add-ons through 10Duke. The add-on’s licensed items are then granted to the same customer identity that the host authenticates.

When the host application belongs to a third party that has no integration with 10Duke Enterprise, the add-on can’t rely on the host’s identity. Instead, the add-on authenticates the user to 10Duke Enterprise itself, at the point the user runs it.

The add-on acts as its own client application. When invoked, it starts an authorization code grant flow with PKCE using the system’s default browser or an embedded WebView, the user signs in to 10Duke Enterprise (or a federated identity provider), and the add-on receives its own access token. It then checks the add-on’s licensed item in a license consumption request, exactly as covered in the rest of this section.

Register the add-on as a dedicated public OAuth client in 10Duke SysAdmin with its own redirect URI, the Detached session attachment, and refresh tokens enabled so the user isn’t prompted on every run. Where the host’s sandbox prevents the add-on from capturing a browser redirect, use the device authorization grant flow instead.

Choose how to model an add-on

In 10Duke Enterprise, you model an add-on as a licensed item. There are two ways to do this, and which one you choose depends on how the add-on is sold and enforced:

Model an add-on as an aggregated licensed item when it’s a feature you switch on or off together with the product. You grant one license on the product, and the add-on comes with it.
Model an add-on as its own (top-level) licensed item when it’s sold or metered on its own. Only a separately granted item can carry its own credit type and license model.

You can use both in the same product configuration—gate simple feature add-ons through aggregation while modeling billable ones as standalone items—and check them all in a single consumption request.

Aggregated feature add-ons

Model the product as a parent (aggregating) licensed item and add each feature as an aggregated licensed item within it. Grant the license on the parent product, and the customer’s license covers every aggregated item it contains. To enable a new feature for all existing licenses, add it to the parent—there’s no need to reissue licenses.

At runtime, the application makes a single license consumption request against the parent product’s licensed item. If enabled in your deployment configuration, the license token’s grantedItems field lists the aggregated items the license grants, and the application enables or hides each add-on accordingly.

This model suits features that are turned on or off as part of a product or tier. Because the license is granted on the parent, aggregated add-ons don’t carry their own credit and can’t be metered individually—if you need that, model the add-on as a standalone item instead.

Standalone add-ons

Give the add-on its own top-level licensed item and license model, and grant it through a product package. Because a product package grants a separate license per licensed item, each add-on is sold, granted, and enforced independently of the base product, and each can use a different license model.

At runtime, the application includes the add-on’s licensed item in the license consumption request. The response indicates, per item, whether it’s granted; an add-on the customer doesn’t hold returns a negative result (for example, noLicenseFound). A single request can include several licensed items, so the application can check the base product and multiple standalone add-ons at once, and enable or hide each based on the result.

This model suits add-ons that are purchased separately or billed by usage. Configure each add-on’s entitlement check and metering with its license model, as described below.

Gate access to an add-on

To control who can use an add-on, use seat-based licensing. A customer who holds the add-on’s licensed item can use it, and everyone else is denied.

Meter add-on usage

To bill by how much an add-on is used, choose count-based metered licensing. For time-based add-ons, choose time-based metered licensing. Because credit type is set per licensed item, the base product and each add-on can use different license models. However, we recommend keeping items of different credit types in separate product packages.

Bundle add-ons with the base product

Grant the base product and any add-ons that share the same credit type together in a single product package. If an add-on uses a different credit type, such as a usage-based add-on paired with a seat-based base product, keep the add-ons in a separate product package, and grant both packages to the customer. This follows our recommendation to use one credit type per package. Regardless of product packaging, a single consumption request can check several licensed items at once, allowing the application to resolve the full set of enabled add-ons in one call.

Implement plugin and add-on licensing

To implement add-on licensing in 10Duke Enterprise, have the host application check each add-on’s licensed item at startup to build the enabled feature set. Re-check metered add-ons when they are invoked. Enable or hide each add-on in your interface based on the result, and treat a negative or error result as “not licensed.”

If a consumption request exceeds the configured limits, the License Consumption API returns a specific error code (for example, noLicenseFound or notAuthorized for an add-on the customer doesn’t hold, licenseQuotaExceeded, or maxUseCountExceed for a metered add-on). See error codes for the full list your application should handle.

For detailed instructions on configuring custom rules and tracking modes in 10Duke SysAdmin, see defining settings for custom license models.