Десктоп приложение / авторизация

Всё что касается построения API
Ответить
german.igortcev
Сообщения: 251
Зарегистрирован: 2014.08.18, 14:01

Десктоп приложение / авторизация

Сообщение german.igortcev »

Привет всем. Опыта в REST есть немного, но не могу найти решение подходящее в моем случае. Нужен совет

Таблица
Пользователи
Компьютеры

Требуется
На удаленном компьютере устанавливаем десктоп приложение, авторизуемся по логину и паролю. Получаем токен для этого компьютера.
Так же рефреш токена переодично.

Смотрел в сторону Oauth2 но не свовсем понял какой больше тип мне подходит.

Поделитесь советом, каким способом реализовать данное для REST. Cпасибо
undestroyer
Сообщения: 120
Зарегистрирован: 2014.01.06, 13:46

Re: Десктоп приложение / авторизация

Сообщение undestroyer »

Как вариант, можно сделать такую oAuth-подобную схему.
Создаете таблицу токенов:
  • access_token (string, токен доступа)
  • refresh_token (string, токен восстановления)
  • access_expire_at (int/dateteime/timestamp, метка времени когда истекает токен доступа)
  • refresh_expire_at (int/dateteime/timestamp, метка времени когда истекает токен восстановления)
  • identity_id (ссылка на сущность, которой выдается токен. Может на пользователя, а может на компьютер, тут смотри по логике своего приложения)
Токен доступа (access_token) - какая-то уникальная строка, которая передается с каждым запросом (скорее всего в заголовках) и по которой мы идентифицируем личность клиента. Он имеет свое время истечения (access_expire_at). В своих продуктах ставлю 24 часа. Когда срок жизни токена доступа истекает, то сервер перестает ему доверять и отдает "413 Не авторизован".
В таком случае смотрим на токен восстановления (refresh_token). Токен восстановления - тоже уникальная в своем столбце строка, и у него тоже есть время жизни (refresh_expire_at). Время жизни токена восстановления должно быть больше времени жизни токена доступа. Например 3 дня.

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

Что нужно учесть для правильной реализации:
  • Если у 1 пользователя может быть несколько клиентов API, то для них нужно делать разные токены
  • При смене пароля пользователя нужно удалять все токены на его клиентах
  • Токен может быть сброшен принудительно, поэтому клиент не должен доверять меткам времени истечения токенов, и должен быть готов к тому, что на самом деле токен уже отозван и больше не валиден
  • Что будет сущностью (identity_id) - решайте сами. Возможно это пользователь, а может комбинация пользователя и компьютера.
  • Хорошо дать пользователю возможность самостоятельно отзывать токены
  • Токенов может быть много, поэтому после истечения срока жизни токена восстановления (refresh_token), хранить его нет смысла и можно удалять, чтобы не занимал лишнего места.
  • Токен доступа передаем в заголовке (x-access-token), а токен восстановления можно отправить POST'ом
Ответить