Все дело в риске, который вы хотите принять.
Если вы сохраните его в файле cookie, вы потенциально можете открыть свое приложение для CSRF.Хотя может иметь смысл обменивать XSS на CSRF, сохраняя токен в файле cookie httponly, не имеет особого смысла делать это с файлом cookie, отличным от httponly, который, кроме CSRF, также уязвим для XSS.
Во многих случаях можно сохранить его в localStorage или sessionStorage.Выбрав это, вы соглашаетесь с тем, что XSS будет иметь доступ к токенам.Чтобы снизить этот риск, вы можете захотеть внедрить меры по снижению риска, такие как, например, статическое сканирование безопасности с помощью подходящего инструмента, регулярное тестирование на пентагентство и т. Д. Безопасность - это не просто код, это также процесс, связанный с созданием этого кода.Приняв меры по смягчению, вы можете принять остаточный риск.
Вы также можете хранить токены в памяти, как, например, в IIFE, я полагаю, откуда их труднее читать при атаке XSS.Хранение в простой переменной не помогает (доступ к javascript из XSS все равно есть), и я не совсем уверен в том, что может сделать последняя версия JS, чтобы безопасно сделать ее недоступной извне данного объекта.Вероятно, это невозможно сделать безопасным способом.
Или вы можете пойти другим путем.Вы можете хранить очень кратковременные токены доступа в localStorage, принимая на себя риск доступа к XSS.Однако ваш IdP может выдавать токены обновления в файлах cookie httponly для домена IdP.Таким образом, даже если токен доступа скомпрометирован, он действителен только в течение ограниченного периода времени, и тогда злоумышленник не сможет его обновить.Это может иметь смысл в некоторых приложениях и, возможно, не в других.