Проверка токенов в REST api

Question

У меня есть простая проблема, у меня есть приложение js (frontend), которое использует мой PHP REST api. Мне нужно реализовать простую аутентификацию на токенах, и я не уверен, как это должно работать, поскольку я не использую сеансы в REST. С моей understaning это звучит примерно так:

1. Пользователь пытается войти в систему, если действительные учетные данные, сгенерировать маркер и возврата объекта пользователя с токена

2. обновляю маркер пользователя в базе данных

3. Клиент хранит объект пользователя в куки или локальном хранилище вместо сеанса и с каждым запросом передает токен в заголовке

4. Я проверяю, есть ли токен в БД, если есть (я знаю, какой пользователь отправка запроса). Я отправляю его на страницу входа в систему. В противном случае я отправлю его на страницу входа в систему.

5. Если токен истекает или пользователь подписывается, я обновляю поле токена в БД с помощью NULL или пустой строки (не уверен, что это необходимо).

Мне просто нужно подтверждение, если это нормально, или я неправильно понял что-то в протоколе. Спасибо всем заранее

Спасибо

Answer 1

Я не думаю, что этот подход не имеет гражданства. Существование токена представляет собой зарегистрированное состояние. Это означает, что часть состояния клиента поддерживается сервером. Другими словами, количество токенов на сервере увеличивается на клиентских сеансах.

каждый запрос от клиента к серверу должен содержать всю информацию, необходимую для понять запрос, и не может воспользоваться любой хранящегося контекста на сервере. Поэтому состояние сеанса сохраняется полностью на уровне клиента . - Fielding - REST - stateless

Я предпочел бы сделать что-то вроде этого:

1. Отправить имя пользователя и пароль в первой аутентификации и возвращает маркер с мета-данными, подписанными сервером.
2. Отправлять маркер любым другим запросом, чтобы сервер мог проверить подпись и использовать метаданные, которые могут содержать, например, идентификатор пользователя, дату истечения срока действия и т. Д.
3. Обновить токен перед он истекает.
4. Регулярно обновляйте закрытый ключ механизма подписи.
5. Кэш данных аутентификации и авторизации с кешем в памяти. Я думаю, что db слишком медленный для этого. Имейте в виду, что весь процесс ДОЛЖЕН работать без кеша. Поэтому, если вы очищаете кеш и отправляете другой запрос, и он не работает, потому что кеш теряется, тогда он нарушает ограничение без ограничений.

Таким образом, вы избежите хранить токен (и, следовательно, состояние клиента) на сервере. Не идеальное решение (например, токен может использоваться другими лицами до истечения срока его действия), но он не имеет гражданства. Я не уверен, действительно ли вам нужен REST или токены на основе auth. (Имейте в виду, что они применяются к связи человека с машиной. Связь между машиной и машиной обычно разрешается по-разному.)

Answer 2

без гражданства. это означает, что на сервере REST не сохраняется какое-либо состояние о клиенте в сеансе или в любой другой форме.

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

Когда наша система используется для выдачи токена доступа, она также создает дату и время истечения срока действия вместе с ним. каждый раз, когда вы делаете вызов с определенным токеном доступа, срок его действия/время обновляется + n hrs