LINUX.ORG.RU

Security tocken в хедере запроса

 , , ,


0

1

Добрый день!
Предвидя вопрос - я знаю, что есть стандартный заголовок basic-auth, но он мне не вполне подходит т.к. имеет лимит на длину.
Есть сервис торчащий в интернет, нужно на часть rest методов навесить авторизацию. Использовать сессии не нужно, т.к. доступ state-less и должен быть только для ограниченного числа систем количеством около 10-20. Нужно сделать простую в использовании авторизацию для внешних систем и мне пришла в голову идея:

  1. Для каждого пользователя завести индивидуальный ключ-строку и токен
  2. Клиент при помощи ключа и random-соли шифрует токен с помощью AES/CBS
  3. Передает с каждым запросов вновь зашифрованную строку «username:salt+encrypted-token»
  4. На стороне принимающего сервиса отделяем соль от запроса, по username получаем ключ шифрования, дешифруем токен и проверяем его на корректность

На сколько жизнеспособной и безопасной является такая схема?

Ответ на: комментарий от matroskin

Так, а чем это будет отличаться от JWT? Разделение на юзеров, ведь тебе не просто так нужно, будет какая-то сlaims-based авторизация?
Если внешние системы имеют одинаковые права, то достаточно просто сгенерировать токены без payload(рандомную строку к примеру).

ritsufag ★★★★★
()
Ответ на: комментарий от ritsufag

С jwt никогда прежде не работал, но как я вижу - для jwt клиенту нужно сделать 2 запроса и хранить на своей стороне пришедшие токены из первого запроса, а вот этого делать не хочется, т.к. это усложнит интеграцию. Данные из запроса шифровать не нужно, там конфиденциального ничего нет, нужно просто ограничить доступ к методам. Как то видится мне jwt оверхэдом в данной ситуации.

matroskin
() автор топика

Ты хочешь заново придумать OAuth2?

ma1uta ★★★
()

Чем это принципиально от Basic авторизации отличается? У каждого клиента есть логин и пароль, у тебя в базе хранятся хэши паролей с солью, никакой AES не нужен, не нужно хранить на сервере никакие ключи клиента. Есть стандартный заголовок Authorization: Basic base64(ivanov:qwerty). Да безопасность такой системы основана на безграничном доверии между клиентом и сервером и защищенном канале, но у тебя по-сути то же самое.

Для нормальной же авторизации между двумя машинами всегда нужно больше одного запроса. Нельзя просто взять и начать посылать запросы с токеном, который клиент сам только что придумал. Иначе не нужны были бы никакие handshake'и в том же https.

В любом случае https тут обязательно, можно прямо иметь белый список клиентских сертификатов и проверять их на сервере. Это избавляет от необходимости выдумывать какие-то свои алгоритмы.

nguseff
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.