CODEWITHSUNDEEP
flutterfirebasefirebase-app-check
actuallynoneed
actuallynoneed

Reputation: 89

Ensuring Secure Backend Access for Mobile App Using Firebase App Check

Our mobile app includes a feature that requires access to an expensive service on our backend. To secure this service and prevent unauthorized access, we have implemented Firebase App Check for authentication. The process involves the app obtaining a token from Firebase App Check for each request, which is then validated by our backend before allowing access to the expensive service.

I have a few questions to ensure we are following best practices:

  1. Is it a good practice to get the Firebase App Check token for each request made by the mobile app? Will this approach impact performance and introduce unnecessary overhead?

  2. Considering that Firebase App Check tokens have a limited validity period (e.g., one hour), should we consider storing the token on the device for a specific amount of time and reuse it for subsequent requests within that timeframe? How can we strike a balance between security and efficiency in this scenario?

  3. If we implement the token storage approach in question 2, could this introduce potential vulnerabilities? For instance, could an attacker potentially replay a previously used token within its validity period and gain unauthorized access to the expensive service?

class SomethingExpensiveService extends ExpensiveService {
  Map<String, String> prepareHeaders(String appCheckToken) {
    return {
      'accept': 'application/json',
      'Content-Type': 'application/json',
      'X-Firebase-AppCheck': appCheckToken,
    };
  }

  @override
  Future<...> makeExpensiveRequest(...) async {
    try {
      var token = await FirebaseAppCheck.instance.getToken();
      var headers = prepareHeaders(token);
      ...
    } catch (e) {
      ...
    }
  }
}

Upvotes: 0

Views: 148

Answers (1)

Frank van Puffelen
Frank van Puffelen

Reputation: 599776

The Firebase App Check SDK itself already stores the token for up to an hour, and return that cached token - unless you explicitly tell it to force a refresh of the token by passing true to the call. So there's no additional need to do this yourself.

During this time period the token can be intercepted and used to impersonate calls coming from your device and app, which is why you should ensure to only send the token over secured connections.

In scenarios where you want to even further reduce the risk of these so-called replay attacks, you can use request a limited use token, which can be used only once. Doing this will affect your application performance (as you need to request a new token more often) and you may into attestation provider limits (as most f those have a quota limit).

Upvotes: 0

Related Questions