結論から言えば、「どちらでもよい」となります。しかし、恐らく話はお考えの内容ほど単純ではないと予想します。

まず、ご質問の回答に入る前に、よくあるCookie vs localStorage論争について。これは、以下の論点に要約されると思います。

Cookie派

• localStorageはXSS脆弱性で簡単に盗まれる。一方、Cookieだと、HttpOnly属性をつけていれば、XSSにより盗まれることはない

localStorage派

• CookieにセッションIDやトークンを保存するとCSRF脆弱性の脅威がある。localStorageにトークンを保存してリクエストヘッダ経由でAPIサーバーに送れば、CSRF脆弱性は原理的に混入しない

これだけを見ると一長一短で、どちらも選べないような気分になりますが、そうではありません。

まず、XSS脆弱性があれば、HttpOnly属性つきのCookieを盗むことはできませんが、XSSによるJavaScriptによりAPIを自由に呼び出すことができます（ここ重要）。なので、サイトの機密情報の盗み取りや、重要機能の悪用はできてしまいます。結局XSS脆弱性そのものを根絶するしかありません。

これについては、以下の動画も参考になると思います。

一方、CSRFの方ですが、確かにCookieを使わなければCSRF脆弱性の可能性はなくなりますが、CSRF対策はフレームワークの機能で簡単に対策できるため、淡々と対策すればよいということになります。

※ なお、SameSite=Strictだけでは完全なCSRF対策にはならないため、結局CSRF対策は必要です。

また、localStorage vs Cookie論争については、以下のスライドおよび動画も参考になるかと思います。

https://www.docswell.com/s/ockeghem/ZM6VNK-phpconf2021-spa-security

さて、肝心のご質問への回答ですが、

IDトークンの保存先として、ブラウザのCookieかサーバーのDBに保存するかの2つの案があると思っています。

サーバーに保存するためには、キーとなる値が必要で、それは結局CookieかlocalStorageに保存するしかありません。そして、そのキー（セッションIDまたはトークン）はXSS脆弱性により悪用されますし、キーをCookieに保存すればCSRF脆弱性の脅威が生まれます。

ご質問の趣旨は、IDトークンそのものを保護したいことだと受け取りました。たしかにIDトークンをサーバー側で保存すれば、IDトークンそのものは漏洩しませんが、サイトの秘密情報漏洩や重要機能の悪用はそれだけでは防げません。

以上から、IDトークンの保存場所はどちらでもよく、なんならlocalStorageでも構いません。

ただ、微妙なところで差があることも確かなので、その微妙なところを問題にしたければ、先に紹介した「SPAセキュリティ入門」をご覧ください。ただ、「入門」となっていますが、「結構難しい」という評判ですw