BASIС аутентификация для REST API плоха?
не удобно, не секьюрно (т.к. логин и пароль приходится передавать каждому клиентскому компоненту, который работает с сервером)
А что вместо?
из минусов: менее стандартно.
скока я сталкивался с апи различных систем, везде это была авторизация с логином и паролем в каждом запросе. Ну иногда еще в запрос включался хэш всех параметров + ключевое слово, заданное и на стороне сервера, и на стороне клиента.
скока я сталкивался с апи различных систем, везде это была авторизация с логином и паролем в каждом запросе.именно для rest-а?
вообще, если делать правильно, то лучше сразу OAuth втыкать.
не, не только rest. Ну можно наверное еще и высылать уже готовый хэш пароля, можно авторизовываться по токену (по сути кука).
не удобно, не секьюрно (т.к. логин и пароль приходится передавать каждому клиентскому компоненту, который работает с сервером)
как вариант: по куке. По крайней мере, такой вариант широкораспространен и с ним все работать умеют.
из минусов: менее стандартно.
Ничего не понял, логин и пароль нужно передавать каждому компоненту и куку тоже надо передавать, так? Где профит? Это не говоря уже о том, что обычно на всю систему бывает 1 клиент к чужой системе, которого остальные части нашей системы просят выполнить тот или иной запрос.
Ничего не понял, логин и пароль нужно передавать каждому компоненту и куку тоже надо передавать, так?логинится один компонент и раздает куку другим компонентам для доступа.
Ок, из нашей беседы я пока вынес для себя, что нужно присмотреться к OAuth (вероятно 2.0). Он у меня ассоциировался больше с авторизацией, чем с аутентификацией и мне пока непонятно, как его можно использовать для REST API. Еще он выглядит сложно, это плохо.
В данном случае этот минус мне не кажется особенно значимым. Вот если бы у тебя была иерархия permission-ов, то да.
P.S. OAuth мощен, но не сказать, чтобы прост в понимании.
А если бы на флокале был OAuth, то я бы приложению выдал ограниченный ключик, который бы позволял ему с моего смартфона читать приваты (но не, к примеру, менять аватарку).
я бы приложению выдал ограниченный ключик, который бы позволял ему с моего смартфона читать приватыВсе равно ты не застрахован от того, что приложение отправит ключик Йожику, и тот прочитает приваты.
верно. Но он хотя бы не продаст мой аккаунт Аджилу.
У топикстартера две системы было, а не одна
Как вы считаете, BASIC auth в таком случае это плохо? Почему, и что нужно использовать вместо?BASIC + HTTPS достаточно секурно само по себе. Другое дело, пароль передается N раз, а не 1 раз - т.е. "в теории" шансов взломать такое больше. На практике я бы заморачивался только если очень много денег на кону.
SPNEGONooooooooooo!
То есть basic аутентификация не так уж и плоха по сравнению с аутентификацией по токенам?
Я вообще считаю что BASIC аутентификация завернутая в HTTPS достаточна для большинства применений (речь идет про remote API для межсистемного взаимодействия).
То есть basic аутентификация не так уж и плоха по сравнению с аутентификацией по токенам?Она просто имеет меньше возможностей в сравнении с токенами, например, нельзя избирательно вырубить сессию, ограничить время жизни и т.п.
Применять все эти токены, хэши, дайджесты внутри SSL "чисто для безопасности" - бессмысленная трата времени, т.к. всё это делает протокол SSL, причем лучше.
Оставить комментарий
psm-home
Каждый раз, когда мне нужно сделать API для удаленного взаимодействия двух систем, я выбираю HTTPS протокол с BASIC аутентификацией (и XML или JSON в качестве payload, но сейчас это не важно). И каждый раз находятся добрые люди, которые говорят мне "это плохо, так не делают". А почему в точности это плохо, не говорят ("ах, это ужасно, мы шлем пароль с каждым запросом"). Ну и что, ведь все завернуто в HTTPS, так?Как вы считаете, BASIC auth в таком случае это плохо? Почему, и что нужно использовать вместо?