@HeyAway

Как подписать токен в RestAPI?

Здравствуйте! Опыта в делах, связанной с аутентификацией, авторизацией, регистрацией, подписями и токена было довольно мало. Информации очень много об этом, но от нее уже голова кругом. Настолько кругом, что нереально сильно запутался. Кхм, к чему это:

Верна ли схема:
1) Пользователь шлет GET-запрос, допустим, на /api/user/auth со своим логином и паролем
3) /api/user/auth проверяет логин:пасс и возвращает данные вида: access_token, refresh_token, sign
4) Пользователь запоминает данные и собирается работать с методом /api/news, отправляя в заголовке access_token и sign
50) Сервер проверяет access_token(на совпадение и не истек ли). Проверяет подпись. Если все хорошо - успех.

Так вот, поделитесь, пожалуйста, опытом того, как собрать подпись? Какие данные туда вложить, чтобы определить, что именно сейчас с API работает нужный, тот самый пользователь? В первый пункт добавить отправку secret, который задаст пользователь? Или в подписи вообще нет необходимости?

Немного подробностей:

Есть приложение, имеется веб-версия. Пользователи - только админы, модераторы, ну и рид онли.
Приложение лишь получает информацию(рид онли). Т.е, например, обращается к методу /api/news и подобного рода.
С одной оговоркой: для подключения push уведомлений, приложению необходимо отравлять данные. Проще говоря, имеется лишь один метод, которому приложение именно отправляет данные.

В веб-версии, имеется возможность создать пользователя(админа, модера, рид-онли), авторизоваться под ним и управлять контентом.

Так вот, уважаемы пользователи тостера, помогите разобраться с кашей в голове. Пожалуйста.
  • Вопрос задан
  • 359 просмотров
Пригласить эксперта
Ответы на вопрос 1
xmoonlight
@xmoonlight
https://sitecoder.blogspot.com
Сцена 1:
Клиент: "Сервер, я хочу авторизоваться"
Сервер: "Да неужели?! Сейчас мы тебя пробьём по нашей базе DNSBL и SpamBL... Ну, вроде нормально. Вот лови TEMPORARY PUBLIC KEY и через 5 секунд жду от тебя логина и пароля, подписанные моим временным ключом! Время пошло!"

Если клиент успел за отведённое время действия публичного ключа верно ввести логин и пароль у себя на клиенте, захешировать, подписать ключом сервера и отправить на сервер - пользователь считается авторизованным.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы