В чем смысл токенов аутентификации в службах REST

Какова ценность использования токена аутентификации при использовании веб-службы REST вместо отправки имени пользователя, пароля через HTTPS/Шифрование каждый раз, когда вы делаете запрос?

Я понимаю, что, например, у OAUTH есть некоторые преимущества, потому что вам не нужно отдать свой пароль третьим сторонам, вы можете передать токен доверенным третьим сторонам, которым вы не хотите делиться именем пользователя/паролем..etc

Но кроме этих особых преимуществ, которые мне, безусловно, не нужны в моем случае, почему я должен использовать токены вместо отправки имени пользователя/пароля каждый раз.

Это может сделать жизнь легкой для клиента, и она не должна отправлять имя пользователя/пароль каждый раз. Хорошо, но теперь клиент должен запомнить мой токен и отправить мне токен по каждому запросу. Поэтому вместо того, чтобы запомнить/отправить имя пользователя/пароль, теперь он будет делать то же самое для токенов! Таким образом, код реализации клиента не получает меньше.

Итак, какова реальная ценность здесь?

Ответ 1

Это действительно зависит от сценария - трудно сказать, не зная больше об API, но использование "токенов аутентификации" далеко не универсально, вы правы, что многие API не нужны (и не используют ) их. Многие API просто требуют, чтобы ключ API отправлялся с каждым запросом (часто через HTTPS, чтобы предотвратить его перехват), или требуется ключ API для идентификации пользователя, а также цифровая подпись с "секретным ключом", чтобы подтвердить идентификацию пользователя (см. При работе с большинством API-интерфейсов, почему им требуются два типа аутентификации, а именно ключ и секрет?).

Имена пользователей/пароли не часто используются в общедоступных API-интерфейсах, поскольку они недостаточно гибки и не обеспечивают достаточного "разделения" между идентификатором пользователя и идентификатором приложения. Например. вы регистрируетесь в качестве разработчика для использования API Flickr и создаете приложение для iPhone, которое использует этот API, - вы действительно хотите, чтобы ваше имя пользователя/пароль разработчика было встроено в приложение? Что делать, если вы позже измените свой пароль? Что делать, если вы хотите развить 5 приложений и отслеживать использование для них отдельно и иметь возможность отключать любое приложение в любое время, не затрагивая других?

Однако для случаев, когда вы действительно хотите идентифицировать только человека-пользователя, а не приложение (например, закрытый API-интерфейс, который будет обслуживать только ваши собственные приложения, а не публичный API), в большинстве сценариев я не посмотрите что-то не так с тем, что вы предложили, т.е. имя пользователя/пароль через HTTPS с каждым запросом. Кстати, у токенов auth есть дополнительное преимущество: "ограничить" (может истечь в определенное время, может быть ограничено только определенными действиями и т.д.), Но, очевидно, это полезно только в очень специфических сценариях.

ТАКЖЕ: как указал пользователь "Дэн" выше, при разработке API, который требует отправки имени пользователя/пароля с каждым запросом (или с любым запросом действительно, даже если это просто запрос на вход), будьте осторожны, как вы это делаете, Если вы используете технику, поддерживаемую браузерами по умолчанию (например, HTTP Basic Auth), вы мешаете себе никогда не подвергать API безопасному доступу к междоменным пользователям (т.е., Скорее всего, ваш API никогда нельзя безопасно вызывать непосредственно из браузера, то есть из кода AJAX/Flash/Silverlight).

Это сложная тема, которая не может быть объяснена здесь полностью, но просто помните, что если ваш API полагается на любые учетные данные безопасности, которые браузер может запомнить, а затем "тихо" вводить в каждом запросе (например, HTTP Basic Auth, cookie), тогда небезопасно разрешать междоменный доступ к этому API с использованием любой междоменной технологии (CORS, JSONP, crossdomain.xml и т.д.).

Ответ 2

Лучший способ ответить на это - указать на эту страницу, описывающую безопасность REST. Он принадлежит к виджету restlet, а не к Джерси, но он может быть применен к Джерси, а также они являются реализациями REST.

Это извлекается из ссылки, которую я предоставил:

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

Такой токен должен быть сложным для вычисления третьей стороной, например. серверный солевой MD5 или SHA1 хэш идентификационных данных пользователя.
Чтобы победить XSRF, этот токен уровня приложения должен быть передан с помощью того, что пользовательский агент автоматически не возвращается с каждым запросом. Например, он может быть отправлен в HTML-форме в виде скрытого поля и возвращен через POST в объект закодированной формы.