How to Protect a Web Application with Licensing Controls

Web applications are technically different from traditional desktop applications in many ways, so they come with their own challenges and options for licensing. A desktop application usually runs on a single end user machine, but a web application runs on a server (or a group of servers) and is reached by many users through a browser. This changes how you bind a license, how you count usage, and how you keep license checks fast under load.

This article covers the main ways you can apply licensing controls to a web application, along with practical considerations for performance and network access.

Decide what the license is bound to

With a desktop application you typically bind a license to a single computer. A web application gives you more options. You can restrict use based on any combination of the following:

• The web server (physical, virtual, or cloud).
• The web site URL.
• The number of active user accounts.
• The number of active sessions.
• Enabled features or modules.
• Usage counters (consumption based licensing).

Most real deployments combine two or more of these so the license matches how the product is actually sold and used.

Licensing by web server (physical, virtual, and cloud)

Binding a license to a physical server is straightforward, because the hardware identity is stable. Virtual and cloud servers are more complicated. A virtual machine can be cloned, and cloud infrastructure can migrate a running instance between physical hosts without warning, so a single issued license can end up running on many duplicated machines.

When you expect customers to run on virtual or cloud servers, plan for that mobility:

1. Offer a build (often at a higher price point) that explicitly permits running on a cloud or virtual server, to offset the higher risk of the virtual machine being cloned.
2. When a virtual environment is detected, use network floating licensing so each instance checks in with a central license server. This lets you track and cap the number of concurrent instances or users instead of relying on hardware identity alone.

For more on the trade-offs of running on virtualized infrastructure, see Concurrent / Network Floating Licensing.

Licensing by web site URL

Licensing by URL is a popular and effective way to tie a web application to a particular web site or organization. Because the license is tied to the site rather than to a specific machine, it works well across multiple servers in a high availability or load balanced setup, and it adapts cleanly to cloud environments where the underlying server may change.

URL based licensing is flexible, so pair it with at least one additional constraint (for example, an active user or session limit). On its own a URL is easy to copy between environments, and the extra constraint discourages a single license from being reused across several deployments.

Licensing by active user accounts

If you sell by the number of users, limit the number of active user accounts. The application enforces the licensed count, and once the limit is reached it prevents new accounts from being added.

To stay flexible for administrators, let them temporarily disable a login rather than delete the account. A disabled login does not count toward the active total, so an administrator can free up a slot for a new user and re-enable the old account later if needed.

Licensing by active sessions

Session based licensing fits products sold by concurrent usage, but HTTP is stateless, so you have to track sessions yourself. The usual approach is to store each session in a database and identify it with a temporary cookie.

To enforce a concurrent session limit reliably:

1. Record the last time each session accessed a page.
2. Automatically close sessions that have been inactive beyond your timeout, so abandoned sessions do not permanently consume a slot.
3. When a user tries to use a session that has already been closed, redirect them to the login page.

Without automatic cleanup of inactive sessions, the licensed count fills up with stale sessions and legitimate users are locked out.

Licensing by features or modules

Feature based (or module based) licensing lets you ship one application and unlock functionality according to what the customer purchased. This is how you offer tiered editions such as Platinum, Gold, and Silver from a single codebase.

When you manage the license centrally, you can change what a customer is entitled to without shipping a new build. After you update the license on the server, the client can refresh and immediately gain access to the newly enabled features.

Licensing by usage counters (consumption based licensing)

Consumption based licensing charges according to actual use, similar to a utility bill or filling a gas tank. The customer purchases a block of credits or tokens in advance and draws them down over time. Your application increments a usage counter for whatever you meter, for example each batch run, each processed record, or each completed transaction, and stops or prompts for more credits when the supply runs out.

This model works well when usage varies widely between customers and a fixed per seat price would not be fair to either side.

Keep license checks fast under load

A web application can serve many concurrent users, so an expensive license check on every request will hurt responsiveness. Two practices keep the overhead low:

• Cache validation results. License validation, especially when it involves cryptographic operations, adds a large amount of overhead if you repeat it on every page request. Validate once and cache the result for a reasonable interval rather than re-validating each time.
• Store licenses in a database rather than the file system. Frequent reads and writes against a license file can cause file locking problems under concurrent load. A database handles concurrent access far better and avoids that bottleneck.

Be mindful of firewalls

If your application phones home to validate and refresh its license, remember that many server environments enforce strict firewall policies that block outbound traffic. An application that cannot reach the license server may fail to validate or refresh. This matters most for mission critical software, where an unexpected license failure is costly, so account for restricted outbound access in your design (for example, by allowing a grace period or supporting a manual refresh path).

Summary

Licensing a web application means choosing the right combination of controls (server, URL, users, sessions, features, and usage) and then implementing them so they stay accurate and fast under real world load. Plan for virtual and cloud mobility, clean up inactive sessions, cache validation results, store licenses in a database, and allow for restricted network access. If you would like help mapping these options to your product, contact SoftwareKey for implementation guidance.