В этом сценарии существует тип предоставления client_credentials, в котором ваш ResServer2 станет как потребителем, так и ресурсом. Поэтому рекомендуемый способ сделать это - настроить его так, но в этом случае ваш ResServer2 не будет иметь никакого пользовательского контекста.
Я столкнулся с похожим сценарием, когда у нас было много устаревшего кода, зависящего от контекста пользователя, и изменение всего механизма авторизации на основанный на политике вариант не был, и я не говорю, что этот подход хорош, но мы в основном настроили наш веб-сайт для запроса областей как для ResServer1, так и для ResServer2, а затем, как только пользователь войдет в систему, а затем запросит защищенные данные у ResServer1, ResServer1 всякий раз, когда ему потребуется запросить защищенные данные из ResServer2, будет просто повторно использовать тот же токен-носитель, который был передан в Оригинальный запрос от WebApp.