Authentication Models

Standard product credential path

Custom HTTP and HISEScript normally use x-ss-app-id, x-ss-plugin-key, and x-ss-plugin-secret with the intended product configuration. Use the endpoint's documented body/header aliases only when supported. Keep secrets out of URLs, logs, public screenshots, and frontend page source.

Rotation/revocation can affect shipped clients. Coordinate updated packages and customer binaries before retiring credentials used by an existing release.

Native package identity is a different path

The current middleware recognizes generated hise-native and juce-native public-client requests using the configured app/product identity. Do not add a shared secret to native public configuration merely because an older custom-HTTP example shows one.

Customer proof, entitlement, machine state, and supported validation/library proof still govern access. A public product ID or native-client marker is not permission to activate someone else's serial or open their library.

Endpoint evidence

Published operations include reviewed fields or an explicit transport contract alongside methods and scope. Read conditional rules, errors, idempotency and example evidence before implementing a request. Source review does not replace seeded request/response testing.

Keep identity and access proof separate

Replace the illustrative device credential and machine ID with values retained after authorized activation. App/product headers identify the application; they do not authorize customer access on their own. Start activation or the supported claim/customer-login flow before validation, and follow the returned denial or reactivation state.

The standard custom-HTTP and HISEScript path instead uses x-ss-app-id, x-ss-plugin-key, and x-ss-plugin-secret. Do not add those shared secrets to generated native public configuration. Use the generated client for its signed response, token/session, persistence, and audio-enforcement rules rather than treating this curl example as a replacement licensing runtime.

Enroll and retain native renewal proof

The generated JUCE client sends device_credential_supported:true during supported activation and validation. Successful enrollment returns device_credential_status:ready and a private device_credential, alongside the short-lived plugin_session_id and its plugin_session_expires_at when available. Save the newest returned proof using the maintained secure storage. The supported body aliases deviceCredentialSupported and deviceCredential map to the same fields.

A device_credential is product/device-bound renewal proof, not a customer login, library bearer token or signed offline grant. A permitted plugin_session_id or validation_token can also validate within its own lifetime; a short-lived proof is not a durable renewal strategy after a long offline period. Do not copy proof between machines or place it in URLs, logs or public screenshots.

If device_credential_status is pending, enrollment is incomplete even when another part of activation succeeded. JUCE reports device_credential_pending, stays locked and retries enrollment automatically. Do not convert this state into offline-valid access or delete the activation to obtain another slot. A completed online validation may then return a verified offline_lease for the Access period; renewal proof alone cannot unlock offline audio.

Confirm the deactivation, not only the request

A confirmed response includes status:deactivated, code:DEVICE_DEACTIVATED and activation_deactivated:true; native session deactivation can also report plugin_session_deactivated:true and remaining_activations. No fresh offline grant is issued. Do not treat any HTTP 200 or an unconfirmed body as proof that the device slot was released.

An unavailable/expired plugin session can return 401 plugin_session_invalid on validation. Keep a valid durable device credential for renewal and follow confirmed entitlement/device denials separately. Deactivation can return 404 DEVICE_ACTIVATION_NOT_FOUND; reconcile the actual activation state rather than claiming a successful release. JUCE keeps its local pending block and protected proof until completion. These illustrative requests do not replace that runtime.

When a session cannot be checked

A signed account token must still match an active stored session. Revoked sessions return 401 SESSION_REVOKED. If the session store cannot be checked, protected account requests stop with 503 SESSION_VERIFICATION_UNAVAILABLE rather than continuing with unverified access.

Retry after a temporary availability problem. Do not treat 503 as permission to bypass authentication or automatically create a second payment, refund or other financial action. Reconcile the specific operation before repeating a write. Product credentials and customer library tokens have separate authentication contracts.

Password changes, recovery codes and sign-out

A successful password change saves the new password and revokes the other stored account sessions together. If revocation fails, the password change is rolled back and the request fails. With a recognized current token, that session is retained; without one, all stored sessions for the account are revoked.

Recovery codes are single-use, including concurrent attempts: only the request that consumes the code can complete that recovery-code sign-in. Disabling two-factor authentication checks the current password and factor against locked current account state. A failed logout returns 503 SESSION_REVOCATION_UNAVAILABLE, not a completed sign-out. Retry and do not treat client-side token removal as confirmation that the server session was revoked.

Native account login with two-factor authentication

The updated JUCE 0.7.3 and HISE Native C++ 0.5.2 sources support the customer account two-factor challenge. Regenerate the complete package, replace the matching sources and rebuild the plugin; an older installed binary does not acquire this behavior from a documentation or server update.

Sign in with the customer email and password. If two-factor authentication is enabled, the account form changes to Authenticator or recovery code. Enter a current authenticator code or an unused recovery code and choose Verify code. A challenge is not a customer session, entitlement or device activation; the plugin remains locked until verified account login and product/device activation succeed.

An invalid code can be retried. An expired challenge requires signing in again. The challenge lasts up to ten minutes and is kept only in the running native client, not the activation cache, logs or public state. Account passwords, two-factor codes and account session tokens are not saved in the license cache. Do not disable two-factor protection to integrate a plugin.