Имеется вебсайт asp.net core, который в качестве логики бэкенда использует набор микросервисов. Стоит задача реализовать авторизацию. Сами микросервисы как я понимаю принимают в качестве авторизации только jwt токены т.к. куки тут не работают. Вижу следующие опции:

1) Юзер авторизуется на веб сервере, получает куку, которая посылается с каждым ajax реквестом. При необходимости обратитися к логике микросервиса, сервер распечатывает куку и генерит из нее токен, куда добавляет все клеймы из куки, после чего делает запрос к микросервису используя этот токен. Из плюсов - кука может быть http only, что не позволит ее угнать XSS атакой.

2) Юзер авторизуется на специальном сервисе (типа OpenID) где получает токен, который хранится в хэдере и клиент напрямую разговаривает с микросервисами используя этот токен. Из плюсов - централизованная генерация токенов и простота общения с микросервисами, из минусов - необходимость сервиса авторизации, плюс токен на клиенте придется хранить либо в Local Storage либо в не http only куке которая может быть прочитана java script'oм и следовательно в случае угона хакер получает контроль над сессией юзера.

3) Юзер авторизуется на специальном сервисе (типа OpenID) где получает токен, который сохраняется в http only куку, клиент делает запросы через веб сервер, который достает токен из куки и передает микросервису.

Что выбрать и почему? Или может еще какие-то варианты есть? Вроде как третий вариант наиболее оптимальный, но смущает необходимость в сервисе авторизации

hVosttно кука тут не при чём, точнее кука это лишь один из немногих способов хранения токена.
мне кажется что кука здесь очень даже причем т.к. от способа хранения кука/не кука зависит могут ли увести сессию. В случае httponly куки не могут, плюс у кукисов есть другие полезные свойства, типа флаг Secure, Same Origin итд. А какие еще есть способы хранения токена помимо куки и local storage? Вроде только эти два