Approov Web Protection Integration
If you have a single API which accepts requests from both the web and mobile channels, then you may appreciate the ability to have shared code for granting access to protected data. The Approov flow has been extended with a facility for integrating other web protection services to enable this.
Approov wraps web protection service results and the Approov service performs the web protection service call normally performed by your backend API. In the Approov configuration you define the duration of an Approov session which is the time period during which a web protection service result, once obtained, should be considered to be valid. During an Approov session no new web protection service results need to be requested, but instead many (short-lived) Approov tokens that contain the original web protection service result can be obtained from the Approov service. This is underpinned by a refresh token, valid for the duration of the Approov session, that is used by the Approov web SDK internally. The Approov service ensures that valid Approov tokens can only be obtained from the browser session that made the initial Approov token request that included the web protection result by using the Demonstrating Proof of Possession (DPoP) protocol. The Approov web SDK can generate a DPoP which that you can, optionally, include in requests to your API in order to provide confidence that the browser session that requested the Approov token is the one that is sending the web API request and that the request has not been intercepted and modified.
The server-side flows of several, best in class, browser solutions have been integrated into Approov to communicate their results back to browsers wrapped in an untamperable Approov token. At a minimum, this enables a single simple token check in the backend API to authorize access. However, if required, Approov can be configured to embed the full results of the integrated protection to allow for deeper interrogation.
There is support for the following web protection services:
- Fingerprint: Fingerprint provides a powerful mechanism for fingerprinting the browser environment of a user and deriving a visitor ID based on both the raw fingerprint and the history of prior visits for that user. This visitor ID can then be compared against a user identity in the backend API system to determine if they match. If they do, then there is a high probability that it is indeed the correct user and operations can proceed. If not, then this may indicate an attempt at account takeover or simply that the user has moved to a different browser environment. In either case, additional verification steps should be introduced into the flow to protect the user’s account.
- Google reCAPTCHA: Google reCAPTCHA is a popular service for determining if a browser is being operated by a human. A browser first retrieves a token from the reCAPTCHA API which is then passed to the protected API as part of a request. A query, from the protected API, obtains the full set of results associated with the token and uses this to determine whether to accept or reject its request.
- hCaptcha: hCaptcha is another popular service for determining if a browser is being operated by a human. To get started, it provides a solution that is a near drop-in replacement for Google reCAPTCHA, however, it also provides further configuration options which extend the capabilities and/or customize behavior. Beyond this, there is also an hCaptcha Enterprise tier.
To use an integration, you must sign up for the associated service, but then follow modified instructions for using those services described in the associated section under Implementing the Integrated Services Flow.
