Activation Code Licensing System Design (Part 3): Activation Flow & Device Lifecycle

3 min read

Learn how activation codes are securely consumed during device activation, how validation and revalidation work, and how to manage the full device lifecycle in a licensing system.

Contents

• Introduction
• Activation Flow
  • Step-by-Step
• Device Lifecycle
  • Local Validation
  • Backend Revalidation
  • Deactivation
  • Device Swaps
• Design Justification

Introduction

Once activation codes are generated, they must be securely bound to devices.
This part explains how activation works, how the system ensures codes are only used once, and how devices are revalidated or deactivated over time.

Activation Flow

Step-by-Step

1. Client submits activation request
   The application sends { code, device_identifier } to the backend.

2. Backend checks usable code

   • Finds a row in activation_codes where:
     • code matches input
     • is_used = 0
     • expire_at > now
   • Confirms the parent constraint is also active.

3. Backend signs payload
   Using its private key, the backend signs { device_identifier, expire_at }.

4. Database transaction

   • Marks the activation code as is_used = 1.
   • Inserts a new row in activated_devices with { code_id, device_identifier, signature, expire_at }.
   • If no valid code is found, nothing is written.

5. Response
   The backend returns { device_identifier, signature, expire_at }.
   The client stores this payload locally.

Device Lifecycle

Local Validation

• On startup, the client checks the stored payload.
• Verifies signature using the public key.
• Ensures now < expire_at.
• If checks fail, the app prompts the user to activate again.

Backend Revalidation

• On startup, the client also calls POST /revalidate.
• Backend joins activated_devices with activation_codes and activation_code_constraints.
• If any part is missing or expired, revalidation fails.

Deactivation

• If a user deletes a code in the portal, the device linked to it is invalidated.
• On the next revalidation, that device fails and must be re-activated.

Device Swaps

• Users can move licenses to new devices by:
  1. Deleting an old code in the portal.
  2. Generating a new one.
  3. Activating the new device with it.
• The old device fails its next revalidation.

Design Justification

• Each code is used once, preventing reuse or replay.
• Devices inherit expiration directly from their constraint.
• Local validation allows offline usage.
• Server revalidation ensures portal actions (like deletion) are enforced.
• Deactivation via deletion keeps UX simple while still enforcing license rules.