1

If I understood AppCheck's workflow correctly, it essentially creates a jwt token with certain expiry based on successful attestation mechanism. Afterwards, all requests containing this jwt are treated as valid and coming from allowed app.

But say someone was to download a legitimate app and inspect their networking to view and copy such jwt token (say in the same way as inspecting network in dev tools in browsers).

This jwt token can then be plugged in to any other app i.e a localhost server and combined with projectid etc... to perform requests that look legitimate, but are now coming from un-authenticated app?

Ilja
  • 44,142
  • 92
  • 275
  • 498
  • This link might help: https://stackoverflow.com/questions/26739167/jwt-json-web-token-automatic-prolongation-of-expiration – ofirule Jan 22 '23 at 13:46

1 Answers1

1

What you are referring to is called a replay attack (intercepting data and retransmitting it). Firebase App Check tokens can be configured to be valid for at least 30 minutes and up to 7 days and the same token can be reused.
However, if you have proper security rules or validation on your custom backend server, this should not be a critical issue.

If you still want to ensure a token can be used only once, you'll have to block the tokens with some custom logic on backed or use the attestation providers like reCAPTCHA directly. From reCAPTCHA's documentation,

Each reCAPTCHA user response token is valid for two minutes, and can only be verified once to prevent replay attacks. If you need a new token, you can re-run the reCAPTCHA verification.

I'm not sure about other providers, but you can write your own logic to prevent reusing tokens.

Dharmaraj
  • 47,845
  • 8
  • 52
  • 84