Как аутентифицировать пользователя с токеном в вызове API?

Question

Я разрабатываю API с использованием PlayFramework, и некоторые конечные точки должны быть защищены аутентификацией. В этих требованиях клиент передает в заголовки HTTP идентификатор пользователя и токен аутентификации, а сервер проверяет.

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

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

Так что мне нужно проверить, имеет ли смысл то, что передается в заголовках, и передается ли оно в теле json (вероятно, проверяется, совпадают ли идентификаторы).

Я сомневаюсь, как этого добиться. Нужно ли создавать разные аннотации для моих методов, чтобы принимать разные типы json и проверять, если заголовок одинаковый?

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

Спасибо!

Answer 1

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

Answer 2

Если я понимаю вашу проблему, я бы сказал, что это проблема авторизации.

Аутентификация против авторизации

Аутентификация - это процесс установления того, что кто-то действительно является тем, кем он себя считает.

Авторизация относится к правилам, которые определяют, кому и что разрешено делать. Например. Адаму может быть разрешено создавать и удалять базы данных, тогда как Усаме разрешено только читать.

Я не знаком с Play Framework, но, вероятно, он обладает теми же функциями, что и другие популярные платформы.

В вашем случае вы должны как-то определить, разрешено ли пользователю изменять некоторые ресурсы. Я не знаю, какой у вас API или контент, поэтому мне просто нужно предложить одно решение.

Надеюсь, этот ответ поможет вам продвинуться вперед и попробовать что-то, что может сработать Если я пропустил какую-то важную информацию, просто спросите больше.

Предположим, у нас есть следующие ресурсы:

/user/1001/address
/user/1002/address

1001 - это идентификатор пользователя A. 1002 - это идентификатор пользователя B.

Теперь, если пользователь А звонит /user/1002/address и пытается опубликовать новые данные, это не должно быть разрешено. Так что теперь у нас есть несколько вариантов авторизации действия.

Первый путь

Вы сказали, что идентификатор пользователя является частью заголовка. Затем в своем действии, прежде чем получить доступ к ресурсу, вы можете проверить, соответствует ли URL ресурса user_id заголовку user_id. Если нет, пользователю не разрешено изменять содержимое.

Конечно, у нас может быть случай, когда администратор сможет это сделать. В Play Framework, вероятно, есть какая-то функция контроля доступа на основе ролей , которая может помочь.

Таким образом, может возникнуть проблема безопасности. Если заголовок содержит идентификатор пользователя A , вызывающий может изменить его и выдать себя за пользователя B .

Второй способ

Почти похоже на первый. Если у вас может быть user_id в вашем контенте JSON, вы можете попробовать подобную логику. Та же проблема безопасности возникает из-за того, что клиент может изменить содержимое и т. Д.

Третий способ (я предпочитаю это)

Если вы используете токен, который может переносить данные, то вы можете использовать эту логику. Я имею в виду, что у вас JWT токен или аналогичная реализация

С этим токеном вам не нужно добавлять идентификатор пользователя в заголовок. Идентификатор пользователя может быть внутри токена. На стороне сервера вы можете читать содержимое с токена.

Теперь, если пользователь A вызывает ресурс /user/1002/address и пытается изменить данные, это больше не должно вызывать проблем. Вы можете просто прочитать user_id из токена и сравнить его с user_id в URL-адресе, например.

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