ペイロードの生の値ではなく、JWTトークンを使用してクエリを実行することをお勧めしますか？
私のSPAアプリでは、認証プロバイダーとしてFirebaseを使用しています。このトークンを使用して、バックエンドサーバーでの認証も行っています。 Firebase documentation は次のように読み取ります。
「警告：バックエンドサーバーでは、GoogleSignInAccount.getId（）メソッドで取得できるようなプレーンなユーザーIDを受け入れないでください。変更されたクライアントアプリケーションは任意のユーザーIDをサーバーに送信してユーザーを偽装できるため、代わりに検証可能なIDトークンを使用して、サーバー側でログインしているユーザーのユーザーIDを安全に取得する必要があります。」
したがって、ユーザー関連のAPI呼び出しの場合、生のuserIdをバックエンドに送信しませんが、代わりに常にJWTトークン全体を送信します。これを確認し、extractこれからuserIdトークン。次に、これをさらにバックエンドロジックに使用します。
私のAPI呼び出しはHTTPSを介して行われ、常に前述のJWTトークンを含む承認ヘッダーが含まれることを考えると、これは良い方法と見なされますか、それとも過剰設計ですか？
私はあなたがあなたの質問に答えるためにあなたがリンクするFirebaseドキュメントのセクション（私は参照のためにそのセクションを下に引用しました）を考える。
これは、アプリケーションにInsecure Direct Object Reference（IDOR）の脆弱性を与えないようにするためのものだと思います。 OWASPにはIDOR脆弱性に関する優れたスライド資料があります 。
IDOR脆弱性の簡単な例は、次のようなURLがある場合です。
https://mybank.com/ViewBalance?userID=7
そして、それをuserID=8に変更すると、他の誰かのバランスを見ることができます。それは良くないね。
基本的に、ユーザーが自分が誰であるかを言うのを信用しないでください。信頼できる認証トークンから読み取ります。あなたのfirebaseドキュメントはそれを正確に言っています：
HTTPS POSTでIDトークンを受け取ったら、トークンの整合性を確認する必要があります。
Google-backed authトークンからuserIDを取得していて、そのトークンを適切に検証する方法についてのGoogleのアドバイスに従っている場合は、おそらくすでに正しく行っています。
たとえば、これはなりすましできないことを自分に納得させるために数分を費やすこともおそらく価値があります。たとえば、JWT署名はどのように機能し、エンドユーザーは署名を偽装できるのでしょうか。 JWTはどのようにクライアントに送信され、どのようにクライアントに格納されますか？攻撃者が別のユーザーのJWTを手に入れるリスクはどのくらいですか？等。
参考までに、ここに Firebaseドキュメントのセクション をリンクします。
IDトークンの整合性を確認します
HTTPS POSTでIDトークンを受け取ったら、トークンの整合性を確認する必要があります。トークンが有効であることを確認するには、次の基準が満たされていることを確認します。
IDトークンはGoogleによって適切に署名されています。 Googleの公開鍵（JWKまたはPEM形式で入手可能）を使用して、トークンの署名を検証します。これらのキーは定期的にローテーションされます。応答のCache-Controlヘッダーを調べて、いつそれらを再度取得する必要があるかを判断します。
IDトークンのaudの値は、アプリのクライアントIDの1つと同じです。このチェックは、悪意のあるアプリに発行されたIDトークンが、アプリのバックエンドサーバー上の同じユーザーに関するデータへのアクセスに使用されるのを防ぐために必要です。
IDトークンのissの値は、accounts.google.comまたは https://accounts.google.com と同じです。
IDトークンの有効期限（exp）が経過していません。
G Suiteドメインのメンバーのみにアクセスを制限する場合は、IDトークンにG Suiteドメイン名と一致するhdクレームがあることを確認してください。
これらの検証手順を実行するために独自のコードを作成するのではなく、プラットフォーム用のGoogle APIクライアントライブラリ、または汎用のJWTライブラリを使用することを強くお勧めします。開発とデバッグのために、tokeninfo検証エンドポイントを呼び出すことができます。