Предположим есть сервер API c аутентификацией.
По большому счету не важно как реализованна авторизация, HTTP basic auth, через Token или oAuth.
В любом из известных способов есть что то, что нужно передать на сервер.
Так вот вопрос: Как быть если нужно реализавать клиента на фроте (javascript к примеру)??
Ведь каждый школьник может открыть source и вытащить из контекста скрипта токен, ключ, логин\пароль.
Возможно кто то скажет: Что даже если злоумышлиник стащит токен или ключ, то это ему не чего не даст, токен должен быть привязан к домены.
Но, что мне помешает сделать запросы, скажет через CURL прописав туда домен с которого я стырил токен?
Цель то какая?
Запретить доступ других клиентов к REST-сервису, кроме как из "родного" браузерного клиента?
Замена имён отправляемых переменных через JS и двойной запрос-ответ (ajax, websocket) при каждом запросе получения/отправки данных на сервер. (этот вариант единственный)
apasen не вполне понятно, почему стоит такая цель. Хорошее REST API - такое, к которому что из официального клиента (в том числе из веб-приложения), что по curl-у - одинаково и по сути дело конкретного пользователя. У вас выходит, что вы имеете какую-то доверенную логику в КЛИЕНТЕ, и вам нужно быть уверенным, что именно ваш клиент отправил запрос. Т.е. вам надо авторизовать клиентский КОД, а не пользователя. Вопрос - зачем вам так надо? Нет возможности эту доверенную логику перенести на сервер?
apasen: такого не бывает. Вопрос только во времени и требуемой квалификации. Проще всего - HTTP/HTTPS, далее WebSockets / TCP без шифрования, и собственно это всё, что можно замутить в браузере и без Flash. Либо сделать как Google - брать не качеством, а количеством - пусть при каждом клике юзера будет алгоритм из 50 запросов, и в каждом по 50 параметров и куков, и все запросы разные. И каждый месяц что-нибудь менять, чтоб боты обламывались. Тогда заказчику будет проблематично оплатить работу умельца, но все равно, сколько веревочка не вейся... Так что задача не реализуема в полной мере.
Да и проблема мне кажется надуманной. Про "любого школьника" - преувеличиваете, 90-99% пользуется браузерными движками, сниффить не умеют, AJAX - непреодолимый барьер для них. А спецы пусть пишут боты на здоровье, не мешайте им нам. Чем больше нам мешают работать, тем хуже получаются боты - и тем, стало быть, больше они мешают вам и юзерам.
Станислав Макаров: Да, если делать запросы с бекэнда, проблем нет, токен скрыт. И увести его не просто.
Но бывают случаи когда у вас single page app, нет бека (весть бек, это то самое апи) - как быть?
apasen я под "бэком" и имею в виду API. И именно этот случай я и рассматриваю.
Я так и не понял в чем ваша проблема/задача. Что или кого вы собираетесь _авторизовать_ - юзера или ваш код? Что или кто и какой токен будет уводить? Кто есть злоумышленник, кто есть жертва и что есть предмет воровства, можете четко объяснить?
"домен с которого я стырил токен" - загвоздка за малым, как "стырить". На затруднение и направлены все методы. Если безопасность сайта настроена хорошо, то "стырить" будет очень затруднительно, но не невозможно. Этот вопрос сродни вопросу об идеальном замке. Но если дверь можно сломать, то какие бы идеальным замок не был, он не поможет. Поэтому в замках есть такое понятие как время противодействия. От нескольких секунд до десятков минут. И тут вопрос в ценности защищаемого "имущества" и в способности администраторов обнаружить вторжение. Но к таким ситуациям надо готовиться заранее.
Простой
Простой
