Ви праві, що при XSS обидва варіанти однаково програють — але це не робить їх рівними. Різниця в тому, ЩО саме дістанеться атакуючому.

Робочий компроміс, який зазвичай і використовують: access-токен живе тільки в пам'яті (звичайне поле сервісу, ніякого стореджу), а refresh-токен лежить у httpOnly + Secure + SameSite кукі. JS до нього не дістається взагалі — ні ваш, ні чужий. При старті вкладки робите тихий refresh на свій ендпоінт, кука їде сама, у відповідь приходить новий access. Тоді XSS може вкрасти максимум короткоживучий access (хвилин на 5-15), а не вічний вхід.

З httpOnly кукою треба закрити CSRF на самому refresh-ендпоінті — SameSite=Strict або окремий anti-CSRF токен, бо інакше чужа сторінка зможе смикнути оновлення.

Щодо «залишкового токена» у другій вкладці — це проблема не сховища, а того, що вихід у вас лише клієнтський. Навіть з localStorage стара вкладка встигне походити з валідним токеном до наступної перевірки таймером. Лікується двома речами: на бекенді при виході ревокуєте refresh (тоді вкладка просто не продовжиться), а між вкладками синхронізуєте вихід через BroadcastChannel — миттєво і без опитування по таймеру.

Для Blazor WASM ще один нюанс: усе, що доступне через JS interop, доступне й атакуючому скрипту, тож «сховати» токен на клієнті неможливо в принципі. Тому питання не де зберігати, а наскільки коротко він живе і чи можна його відкликати.