Блог

В моем REST API пользователь впервые войдет в систему под своим именем пользователя и паролем.

Когда они успешно войдут в систему, мы ответим в следующем формате.

 {
  "token": "0c7f8b870675bc61d92baeef1e274c2d31343736393530373230",
  "expire_on": "2016-11-19T18:05:20 0000",
  "user_id": 30,
  "user": {...}
}
  

В следующем за REST API мы просто отправим token заголовок для проверки пользователя. token это 52 длинные буквы.

Достаточно ли это безопасно?

Должен ли я отправлять оба token и user_id для проверки, чтобы обезопасить больше?

Это зависит от того, как вы генерируете свой токен. Если кто-то может догадаться, как они генерируются, он может создать поддельный. Если это случайная строка, которая сохраняется на вашем сервере, и для каждого запроса вы проверяете ее существование на своем сервере, тогда вы в безопасности. Лучшим текущим решением для токена без состояния является JWT. Взгляните на https://jwt.io /

Реализовали ли вы свой уровень аутентификации? Я бы посоветовал взглянуть на спецификацию Oauth2, и вас интересует раздел, в котором grant_type является паролем. Если вы выполните его, будет безопасно вернуть только токен доступа:

5.1. Успешный ответ

Сервер авторизации выдает токен доступа и необязательный токен обновления и создает ответ, добавляя следующие параметры в тело объекта HTTP-ответа с кодом состояния 200 (OK):

ТРЕБУЕТСЯ access_token. Токен доступа, выданный сервером авторизации.

ТРЕБУЕТСЯ token_type. Тип выданного токена, как описано в разделе 7.1. Значение не зависит от регистра.

РЕКОМЕНДУЕТСЯ ИСПОЛЬЗОВАТЬ expires_in. Время жизни токена доступа в секундах. Например, значение «3600» означает, что токен доступа истечет через час с момента генерации ответа. Если этот параметр опущен, сервер авторизации ДОЛЖЕН указать время истечения срока действия другими способами или задокументировать значение по умолчанию

.