Tokens and Protection Keys

Your project in Liteguard has two kinds of credentials: Project Client Tokens and Protection Keys. They serve different purposes and should be handled differently.

Both live on the project detail page in Config > [workspace] > [project].

Project Client Token

A Project Client Token is the credential your application passes to the Liteguard SDK when initializing the client. The SDK uses it to authenticate with Liteguard and fetch the guard bundle for your project and environment.

Token values start with pcid-.

What the SDK does with it

When you call new LiteguardClient('pcid-...'), the SDK includes the token in its request to the Liteguard backend to retrieve the guard bundle. The backend uses the token to identify which project and environment the client belongs to. After the initial fetch, the SDK refreshes the bundle in the background at the configured interval.

Where to use it

Pass the token at SDK initialization time. In server-side code, read it from an environment variable:

const client = new LiteguardClient(process.env.LITEGUARD_TOKEN!);

In client-side browser code, the token is included in the built application. This is acceptable because the token only grants access to the public guard bundle for your project, which is not sensitive.

Security and rotation

Treat a Project Client Token like any other API key.

Do not commit it to source control.
Store it in a secrets manager or environment variable in CI and production.
If a token is compromised or you want to rotate it, create a new token in the project detail page first, deploy the new token to your infrastructure, and then disable the old token after the new one is in use everywhere.

A project can hold up to two tokens at once to support zero-downtime rotation. The Rotate option in the token menu automates the first step (creating a replacement token) and reminds you to disable the old one after deployment.

Managing tokens in the UI

On the project detail page, the Project Client Tokens section lists all tokens for the project. Each entry shows the last eight characters of the token value and its enabled or disabled status.

The menu button next to each token offers:

Copy — copies the full token value to the clipboard.
Rotate — creates a new token in preparation for a rotation.
Disable — prevents the token from being used without deleting it.
Delete — permanently removes the token.

To create a first token or an additional token, click New Token at the top of the section.

Protection Key

A Protection Key is used exclusively for the protected context feature. You only need a Protection Key if your application uses a trusted backend signer to sign context properties for the SDK.

Key values start with ppk-.

If you are not using protected contexts, you can ignore this section entirely.

What protected context is

Normally, properties passed to isOpen from client-side code are not trusted — an end user could theoretically pass any value they want. Protected contexts solve this for sensitive properties such as userId, plan, or any value where the integrity of the data matters for your guard rules.

The pattern works like this:

Your backend signs a payload containing verified properties using the Protection Key.
The signed payload (a ProtectedContext object containing a signature and properties) is passed to your SDK.
The SDK includes the signature when fetching the guard bundle.
Liteguard verifies the signature using the corresponding Protection Key and, if valid, returns a guard bundle that can evaluate rules against the signed properties.

Because the signature is produced server-side with a key that never leaves your backend, the client cannot forge or tamper with those property values.

When you need one

You need a Protection Key when:

Your guard rules reference properties that must be server-verified, such as a real userId or subscription tier.
You are using the bindProtectedContext SDK method to attach signed properties to a scope.

You do not need a Protection Key for rules that evaluate properties passed directly at the isOpen call site without a signature requirement.

Managing protection keys in the UI

On the project detail page, the Protection Keys section lists all protection keys for the project. The menu next to each key offers copy, disable, and delete options. Disabling a Protection Key causes any backend signer still using it to produce signatures that Liteguard rejects until the signer switches to an active key.

To add a key, click New Protection Key at the top of the section.

Security

A Protection Key must never leave your backend. It should not be shipped in client-side code, mobile bundles, or any environment where it could be extracted. Unlike a Project Client Token, a Protection Key represents a trust assertion. If it is exposed, an attacker could sign arbitrary context values.

Store it as a server-side secret using your secrets management tooling, the same way you would treat a private signing key or database credential.

Summary

	Project Client Token	Protection Key
Purpose	Authenticate the SDK to fetch the guard bundle	Sign protected-context payloads on your backend
Used by	SDK client in your application	Your trusted backend signer only
Safe in client-side code?	Yes	No
Required for basic use?	Yes	Only for protected contexts
Starts with	`pcid-`	`ppk-`

Tokens and Protection Keys ​

Project Client Token ​

What the SDK does with it ​

Where to use it ​

Security and rotation ​

Managing tokens in the UI ​

Protection Key ​

What protected context is ​

When you need one ​

Managing protection keys in the UI ​

Security ​

Summary ​