# MobileID InApp app attestation
We offer App Attestation as a security feature to guarantee that our Encap server is communicating with the correct app.
By default, any client with a valid AppID and E2E public key can call and use our Encap mobile client APIs. This could allow a third party to create a malicious app, which can pose security and privacy risks. App Attestation gives applications additional security as it prevents third-party use of our APIs.
# How does app attestation work?
On Android devices, we offer SafetyNet, which is provided by Google as part of the Android platform.
SafetyNet provides a set of services and APIs that help protect an app against security threats, including device tampering, bad URLs, potentially harmful apps and fake users.
Specifically, we make use of the SafetyNet Attestation API (opens new window), which assesses the integrity of the device that an app is running on. No similar API currently exists for iOS.
SafetyNet Attestation can be used in different modes:
OFF: This is the default mode until Signicat has completed configuring the feature for you. No SafetyNet attestation is performed.
OPTIONAL: Useful for temporary use transition periods, such as upgrading existing Encap server and client SDK installations. Authentication will be possible even if a SafetyNet check fails, but you will be able to monitor logs for successful vs. failed SafetyNet checks.
REQUIRED: If a SafetyNet check fails, the authentication request will be blocked.
If your app generates more traffic than the default SafetyNet API quota, your API requests may return errors. You can find more details in the section on SafetyNet API quota and monitoring (opens new window) in the Android developer documentation.
On iOS devices, app attestation relies on the app signature, which guarantees that the server communicates with the correct app. This is achieved by using intermediate push notifications.
# Intermediate push notifications
Intermediate push prevents emulated devices and other apps from performing successful activations and authentications. No configuration is necessary from your side.
The usual flow is as follows:
- The client sends the push address during the initial request for the session.
- The server creates a nonce and sends it to the push address.
- The legitimate client app receives the nonce in the push message.
- The client app creates a MAC of this nonce and sends it to the server along with the subsequent request.
- The server validates the MAC of this latest nonce against the original one.
The binding between the app and the push message is based on the app's publishing certificate as well as the push certificate, which must both belong to the same app or developer account, depending on configuration.
Contact Signicat at firstname.lastname@example.org if you would like us to set up app attestation for you.
# Further reading
- MobileID InApp overview
- Mobile app-initiated operations via OIDC
- Mobile app-initiated operations: URL construction
- Mobile app-initiated operations: Finalise operation
- Backend-initiated operations via OIDC
- Backend-initiated operations: URL construction
- Backend-initiated operations: Finalise operation
- MobileID InApp upgrade guide
- MobileID InApp release notes