RESTful-аутентификация

Question

Что означает аутентификация RESTful и как она работает? Я не могу найти хороший обзор в Google. Насколько я понимаю, вы передаете сеансовый ключ (запоминающийся) в URL, но это может быть ужасно неправильно.

Answer 1

Это способ сделать это: Использование OAuth 2.0 для входа в систему .

Вы можете использовать другие методы аутентификации, отличные от Google, если они поддерживают OAuth.

Answer 2

Использование инфраструктуры открытого ключа, в которой регистрация ключа включает в себя надлежащую привязку, гарантирует, что открытый ключ привязан к индивидууму, которому он назначен, таким образом, что не допускается отказ

См. http://en.wikipedia.org/wiki/Public_key_infrastructure. Если вы соблюдаете надлежащие стандарты PKI, лицо или агент, который неправильно использует украденный ключ, может быть идентифицирован и заблокирован. Если агенту требуется использовать сертификат, привязка становится довольно жесткой. Умный и быстроходный вор может сбежать, но они оставляют больше крошек.

Answer 3

Чтобы ответить на этот вопрос из моего понимания ...

Система аутентификации, которая использует REST, так что вам не нужно фактически отслеживать или управлять пользователями в вашей системе. Это делается с помощью HTTP-методов POST, GET, PUT, DELETE. Мы берем эти 4 метода и рассматриваем их с точки зрения взаимодействия с базой данных как CREATE, READ, UPDATE, DELETE (но в Интернете мы используем POST и GET, потому что это то, что сейчас поддерживают якорные теги). Таким образом, рассматривая POST и GET как наши CREATE / READ / UPDATE / DELETE (CRUD), мы можем разработать маршруты в нашем веб-приложении, которые смогут определить, какое действие CRUD мы достигаем.

Например, в приложении Ruby on Rails мы можем построить наше веб-приложение таким образом, чтобы, если пользователь, вошедший в систему, посещал http://store.com/account/logout, то GET этой страницы можно было увидеть как пользователь, пытающийся выйти из системы. В нашем контроллере rails мы создали бы действие, которое выводит пользователя из системы и отправляет его обратно на домашнюю страницу.

GET на странице входа даст форму. POST на странице входа в систему будет рассматриваться как попытка входа в систему, при этом данные POST будут использоваться для входа в систему.

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

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

Answer 4

Советы действительны для защиты любого веб-приложения

Если вы хотите защитить свое приложение, , тогда вам определенно следует начать использовать HTTPS вместо HTTP , это обеспечивает создание безопасного канала между вами и пользователями, что предотвратит прослушивание данные, отправляемые назад и вперед пользователям, помогут сохранить конфиденциальность обмена данными.

Вы можете использовать JWT (JSON Web Tokens) для защиты API RESTful , это имеет много преимуществ по сравнению с сеансами на стороне сервера, преимущества в основном:

1 - Более масштабируемый, так как ваши серверы API не должны будут поддерживать сеансы для каждого пользователя (что может быть большим бременем, когда у вас много сеансов)

2 - JWT являются самодостаточными и имеют утверждения, которые, например, определяют роль пользователя, доступ к которому он может получить, а также дату и дату истечения срока действия (после чего JWT не будет действительным)

3 - Проще обрабатывать балансировщики нагрузки, и если у вас есть несколько серверов API, поскольку вам не нужно обмениваться данными сеанса или настраивать сервер для перенаправления сеанса на один и тот же сервер, когда запрос с JWT попадает на какой-либо сервер. может быть аутентифицирован и авторизован

4- Меньшая нагрузка на вашу БД, а также вам не придется постоянно хранить и извлекать идентификатор сессии и данные для каждого запроса

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

Многие библиотеки предоставляют простые способы создания и проверки JWT на большинстве языков программирования, например: в node.js одним из самых популярных является jsonwebtoken

Поскольку REST API, как правило, стремятся сохранить сервер без сохранения состояния, JWT более совместимы с этой концепцией , поскольку каждый запрос отправляется с токеном авторизации, который является автономным (JWT) без сервер должен отслеживать сеанс пользователя по сравнению с сеансами, которые делают сервер настроенным так, чтобы он запоминал пользователя и его роль, однако сеансы также широко используются и имеют свои плюсы, которые вы можете искать, если хотите.

Важно отметить, что вам необходимо безопасно доставить JWT клиенту, используя HTTPS, и сохранить его в безопасном месте (например, в локальном хранилище).

Подробнее о JWT можно узнать по этой ссылке