Нужен reverse proxy (далее просто «прокси»), который получая запрос, перенаправляет его в некое api. Из полученного результата получает куки и сохраняет их в свой сторадж (например в redis). При последующих запросах сохранённые куки в сторадже должны передаваться в запросах к api.
Куки в сторадже прокси должны актуализироваться. Например, когда в ответе от api прилетают не те значения, что в сторадже прокси. Или например когда api отвечает заголовками, что кука должна быть удалена – в сторадже она тоже должна быть удалена.
Для идентификации запросов – использовать гет-параметр vk_user_id. Он и другие параметры, начинающиеся с vk_ – подписываются подписью, которая передаётся в гет-параметре sign. Нужно сверять подпись с переданными гет-параметрами и в случае несопадения – отвечать 403 http-статусом (тело ответа дадим отдельно). Подробнее про подпись параметров:
Api, в которое прокси отправляет запросы работает по https.
Прокси должен «отрезать» все куки, которыми отвечает api и не отдавать их наружу.
Запросы, отправляемые от клиентов к прокси могут быть параллельными (в том числе для одного и того же vk_user_id), то есть можно получить состояние «гонки» как на чтении из стораджа кук, так и на запись. Нужно сделать, чтобы эти ситуации обрабатывались корректно. Но нужно предусмотреть возможность выключения детекта и обработки ситуаций с гонками (api может отвечать не очень быстро, и, возможно, нам будет больше подходить не всегда «корректное» поведение, чем когда запросы от клиентов будут вставать в очередь, ожидая ответов от api).
Креденшены и необходимые параметры – после согласования работ по задаче.