Является ли идентификатор в этом случае избыточным с токеном?

Question

Я работаю над проектом, который я сделал год за go, и я на самом деле забываю, о чем я думал в то время.

Существует связь между моим сервером и сервером моего клиента через HTTP POST.

Мой сервер отправляет список, сообщающий серверу клиента, какие данные мне нужны, все запрашиваемые данные имеют уникальный идентификатор, а сервер клиента отправляет обратно список идентификатора, пара данных.

Например, : Мой сервер отправляет

[{id: 1001, input: 40.2},
 {id: 2033, input: 326.4},
 {id: 4212, input: 67.12},
 {id: 9551, input: 5.3}]

Сервер моего клиента отвечает

[{id: 1001, output: 3144},
 {id: 2033, output: 4362},
 {id: 4212, output: 6428},
 {id: 9551, output: 2319}]

Сервер моего клиента может ответить пустым списком, а затем отправить данные позже через другой API.

Чтобы сервер клиента не получил поддельный запрос, мой сервер отправит key вместе со списком. Клиент может увидеть этот ключ на странице консоли и установить его на своем сервере.

Чтобы наш сервер не получал поддельные ответы или ложные данные, клиент должен отправить свои Customer ID и API key вместе со списком ответов. , Они могут видеть это на странице консоли.

Странно то, что записи списка не только имеют id, но также имеют случайно сгенерированный token. Таким образом, списки на самом деле выглядят следующим образом.

Мой сервер отправляет

[{id: 1001, token: dgkldjktle34512fas, input: 40.2},
 {id: 2033, token: gt23k4652bkjte24ks, input: 326.4},
 {id: 4212, token: 35wfvjnsl34342ldsa, input: 67.12},
 {id: 9551, token: eftrlh44yw3.dflk3r, input: 5.3}]

Сервер моего клиента отвечает

[{id: 1001, token: dgkldjktle34512fas, output: 3144},
 {id: 2033, token: gt23k4652bkjte24ks, output: 4362},
 {id: 4212, token: 35wfvjnsl34342ldsa, output: 6428},
 {id: 9551, token: eftrlh44yw3.dflk3r, output: 2319}]

Если ответившие данные имеют неверный токен, мой сервер будет не принять его.

Но теперь я путаюсь, зачем мне токен в списке?

Проверка API key уже предотвращает ложный ответ или ложную отправку данных.

Это бесполезная избыточность? Или есть сценарий, о котором я думал раньше, но забыть сейчас?

Answer 1

Токен не позволяет вам получить ответ, фактически не запрашивая ничего, чуть-чуть похожего на CSRF. Обратите внимание, что ваша схема отправки ключей для аутентификации может быть улучшена. В настоящее время, если я правильно понимаю, человек в середине атакующего (который может быть прокси, даже в случае https (tls), который всегда должен быть) может изменять значения, тогда как общий секретный ключ может использоваться для применения аутентификации сообщений (например, . HMA C), чтобы гарантировать, что данные действительно являются тем, что было отправлено в любом направлении.