For my SPA app, I'm using Firebase as the authentication provider. I'm also using this token to authenticate with my back-end server. The Firebase documentation reads:

"Warning: Do not accept plain user IDs, such as those you can get with the GoogleSignInAccount.getId() method, on your backend server. A modified client application can send arbitrary user IDs to your server to impersonate users, so you must instead use verifiable ID tokens to securely get the user IDs of signed-in users on the server side."

So for my api calls that are user related I don't transmit the raw userId to my backend but instead I always send the whole JWT token which I proceed to verify it and extract the userId token from this. I then use this for my further back-end logic.

Considering that my api calls are over HTTPS and will always contain an authorization header with the said JWT token, is this considered a good practice or am I over-engineering it?

1 Answer 1


I think the section of the Firebase docs that you link to answers your question (I've quoted that section below for reference).

I believe this is trying to avoid you putting Insecure Direct Object Reference (IDOR) vulnerabilities into your application. OWASP has a great slide deck about IDOR vulns.

The simple example of IDOR vuln is when you have a URL like this:


and if you change it to userID=8 then you can see someone else's balance. That's bad.

Basically, never trust the user to tell you who they are; read that from a trusted authentication token. Your firebase docs say pretty much exactly that:

After you receive the ID token by HTTPS POST, you must verify the integrity of the token.

If you're getting the userID from a google-backed auth token, and you're following Google's advice for how to properly validate that token, then you're probably doing right already.

It's probably also worth spending a few minutes convincing yourself that this can't be spoofed, for example: how does the JWT signature work and could an end-user spoof a signature? How are the JWTs transmitted to the client, and how are they stored at the client? How big is the risk that an attacker could get hold of another user's JWT? Etc.

Just for reference, here is the section from the Firebase docs that you link to:

Verify the integrity of the ID token

After you receive the ID token by HTTPS POST, you must verify the integrity of the token. To verify that the token is valid, ensure that the following criteria are satisfied:

  • The ID token is properly signed by Google. Use Google's public keys (available in JWK or PEM format) to verify the token's signature. These keys are regularly rotated; examine the Cache-Control header in the response to determine when you should retrieve them again.

  • The value of aud in the ID token is equal to one of your app's client IDs. This check is necessary to prevent ID tokens issued to a malicious app being used to access data about the same user on your app's backend server.

  • The value of iss in the ID token is equal to accounts.google.com or https://accounts.google.com.

  • The expiry time (exp) of the ID token has not passed.

  • If you want to restrict access to only members of your G Suite domain, verify that the ID token has an hd claim that matches your G Suite domain name.

Rather than writing your own code to perform these verification steps, we strongly recommend using a Google API client library for your platform, or a general-purpose JWT library. For development and debugging, you can call our tokeninfo validation endpoint.

  • 1
    Sweet. Thanks for the answer. So I'm basically on the right track by always supplying the whole JWT token to my back-end server, as opposed to just the user ID.
    – kingJulian
    Mar 27, 2020 at 23:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .