43 Introduction to App Trust

This chapter introduces App Trust, explaining how it uses third-party attestation and time-bound tokens to help ensure only genuine applications and trusted devices can access Oracle Backend for Firebase-protected backend services.

• Overview
  
• Request Flow After App Check Activation
  
• Supported Platforms and Providers
  

43.1 Overview

App Trust helps protect the Oracle Backend for Firebase backend service from abuse by preventing unwanted traffic from using backend services. It leverages third-party attestation providers to validate whether a request is coming from a genuine client.

Before any request reaches your backend, App Trust uses a third-party attestation provider — reCAPTCHA, hCaptcha, or Cloudflare Turnstile — to ask "Is this request coming from a real user running a real version of your app?" If the answer is yes, the provider issues a short-lived token, and the SDK attaches that token to every outgoing request. If the answer is no — or no token is sent at all — the backend rejects the request with a 403.

With App Check enabled, devices running your app use an app or device attestation provider that attests to one or both of the following:

• Requests originate from your authentic app

• Requests originate from an authentic, untampered device

43.2 Request Flow After App Check Activation

Once App Check is activated for a service and the client SDK is integrated, a background verification cycle is established:

1. The SDK asks the attestation provider (reCAPTCHA, hCaptcha, and so on) to verify the request is coming from a trusted environment.
2. The provider returns a proof: the Oracle Backend for Firebase backend validates that proof against the credentials you configured for the app.
3. The backend issues a short-lived App Trust token: the SDK stores it and refreshes it automatically before it expires
4. The SDK attaches the token to every backend request: auth calls, database reads/writes, storage operations.
5. The backend checks the token on each request: Valid token → request goes through. Missing or invalid → 403.

Positive Case

When everything is working correctly:

• The app successfully gets an App Trust token from the attestation provider
• The token is automatically attached to outgoing requests
• The backend service verifies the token successfully

Negative Case

Cases that result in failure include:

• No AppTrust token is sent
• Token is expired, tampered, or invalid
• Request is coming from:
  • Script/bot
  • Unauthorized client
  • Modified app

Expected result: Error 403

43.3 Supported Platforms and Providers

App Trust provides built-in support for web applications, with support including the following services:

• Authentication
• Database
• Storage

The following attestation providers are supported:

• hCaptcha
• reCAPTCHA v3
• Cloudflare Turnstile
• reCAPTCHA Enterprise

You pick which one to use when you set App Trust up — most apps need exactly one. If you're not sure, reCAPTCHA v3 and Turnstile are the most common starting points for transparent, behind-the-scenes verification (no checkboxes for users to click).