Approov Glossary
This glossary collects the principal Approov concepts used throughout the documentation. Terms are sorted alphabetically, and each term links to the most relevant documentation page or section.
| Term | Definition |
|---|---|
| Account Message Signing | Message signing using a managed key associated with the Approov account. |
| Account secret key | The symmetric account-level key used by default to sign or encrypt Approov tokens. |
| Annotation policy | The part of a security policy that determines which detected properties may be included in an Approov token. |
| API domain | A hostname registered with Approov for token issuance, pinning, or managed trust-root protection. |
| App authenticity | Confirmation that an app is an official build recognized through its signing identity or registration. |
| App registration | A record identifying a specific app package or build that Approov should accept as authentic. |
| App signing certificate | A public signing certificate registered with Approov so builds signed by it can be recognized as official. |
| Apple App Attest | An optional Apple attestation signal that Approov can require and validate for supported iOS apps. |
| Apple DeviceCheck | An Apple service integrated by Approov to confirm real hardware and maintain limited per-device state. |
| Application Installation Attributes | Backend-signed data attached to an app installation and subsequently included in the Approov token's embed claim. |
| Approov | An app and API security service that verifies the authenticity and runtime integrity of an app before its API requests are trusted. |
| Approov account | The administrative boundary containing an organization's apps, API domains, policies, keys, users, and metrics. |
| Approov CLI | The approov command-line tool used to configure and operate an Approov account. |
| Approov cloud service | The server-side Approov infrastructure that analyzes attestation data and issues Approov tokens or secure strings. |
| Approov SDK | The library integrated into an app that performs security checks, communicates with Approov, and obtains tokens or secure strings. |
| Approov token | A short-lived JWT conveying the result of Approov attestation to a backend API. |
| Attestation | The process in which the SDK and Approov service evaluate an app's authenticity and runtime environment. |
| Attestation Response Code (ARC) | An optional encoded token claim containing the pass/fail result and selected device-property information. |
| Auto-registration | Recognition of compatible app builds from an approved signing certificate without registering every build individually. |
| Backend integration | The server-side logic used to verify tokens, inspect claims, or enforce Approov decisions. |
| Blocking / enforcement | Rejecting API requests that do not contain an acceptable Approov token. |
| Chargebee | Some Approov customer payments are handled through Chargebee. If your billing comes from Chargebee, you can reach your customer record at the link. |
| Claim | A named value carried in a JWT payload, such as expiry, device ID, audience, or attestation information. |
| Custom device | A specifically identified device for which detailed information or a device-specific policy is configured. |
| Device filter | A rule that matches device information for metrics, investigation, policy assignment, or banning. |
| Device ID | An identifier for a particular app installation; it may change if the app is reinstalled. |
| Device property | A security-relevant condition detected during analysis, such as rooting, jailbreaking, debugging, emulation, or app tampering. |
| Dynamic configuration | Signed configuration delivered to the SDK over time, including updates such as API-domain trust information. |
| Dynamic pinning | Secure over-the-air management of the trusted public-key pins used by an app. |
| Example token | A CLI-generated token used to test backend verification without requiring a live app fetch. |
| Explicit pinning | Restricting a domain to specifically configured certificate public keys. |
| Failover service | Approov's secondary cloud system, which can continue issuing tokens during a primary-service failure with a reduced analysis set. |
| Force pass / force fail | An administrative override that causes a particular device or app to pass or fail attestation. |
| Google Play Integrity | An optional Google integrity signal incorporated into Approov's Android assessment. |
| Initial SDK configuration | The fixed bootstrap configuration used to initialize the SDK and authenticate subsequent configuration updates. |
| Installation Message Signing | Message signing using a key unique to an individual app installation. |
| Invalid Approov token | A deliberately non-valid token returned when attestation is rejected, allowing the backend to enforce the result without exposing it to the client. |
| JWE | JSON Web Encryption; an encrypted JWT format used when token claims must remain confidential. |
| JWKS | JSON Web Key Set; a standard JSON representation of cryptographic keys used by JWT systems. |
| JWS | JSON Web Signature; a signed, readable form of JWT used by default for Approov tokens. |
| JWT | JSON Web Token; the standard container format used for Approov tokens. |
| Key set | A managed collection of named signing or encryption keys that can be assigned to API domains. |
| Loggable token | A reduced diagnostic representation designed to be safer and more useful in application logs than a complete Approov token. |
| Long-lived Approov token | An administratively generated token intended for controlled testing or server-to-server use, never for embedding in public clients. |
| Managed Trust Roots | Approov's default connection policy, which permits certificate chains leading to an approved set of certificate-authority roots. |
| Man-in-the-Middle (MitM) | An attacker or intercepting proxy positioned between an app and a service, potentially able to inspect or alter traffic. |
MITM_DETECTED | A fetch result indicating that the secure connection to Approov appears to be intercepted; it is distinct from policy rejection. |
| Monitoring mode | An operational phase in which Approov results are measured without rejecting otherwise valid API requests. |
| Option flag | A fine-grained setting that enables a particular security-policy behavior or requirement. |
| Public-key pin | A hash identifying an approved certificate public key for a TLS connection. |
| Rejection policy | The part of a security policy that determines which detected properties cause attestation to fail. |
| Rejection reason | A device property or unmet requirement that caused an attestation to fail. |
| Runtime integrity | The assessed security state of the environment in which an app is running. |
| Secure string | A secret stored in the Approov cloud and delivered just in time only to apps that pass attestation. |
| Security policy | The account- or device-level configuration governing security rules, rejection behavior, and token annotations. |
| Security rules | Dynamically updated checks used to detect security-relevant properties of an app and its runtime. |
| Token binding | Binding an Approov token to other request data, such as a user authentication token, through a payload hash. |
| Token fetch | A request by the SDK to obtain an Approov token for a particular API domain. |
| Token lifetime | The period during which an Approov token remains usable; mobile tokens are normally short-lived. |
| Token verification | The backend process of cryptographically checking an Approov token before accepting an API request. |
| User role | A set of permissions controlling CLI access to an Approov account, such as admin, dev, delegate, pentest, or automation. |
| Valid Approov token | A token with the expected cryptographic validity, indicating that the app passed the applicable Approov policy. |
| Web Protection | Approov token issuance for web clients using integrated browser, fingerprinting, or challenge-provider results. |