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

rest authentication restful-authentication rest-security

359240 просмотра

14 ответа

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

Автор: Jim Keener Источник Размещён: 17.05.2019 04:01

Ответы (14)


535 плюса

Решение

Как обрабатывать аутентификацию в архитектуре RESTful Client-Server является дебатом.

Как правило, это может быть достигнуто в SOA через HTTP через:

  • HTTP basic auth over HTTPS;
  • Cookies и управление сессиями;
  • Токен в заголовках HTTP (например, OAuth 2.0 + JWT);
  • Аутентификация запроса с дополнительными параметрами подписи.

Вам придется адаптироваться или даже лучше смешивать эти методы, чтобы в лучшем случае соответствовать вашей архитектуре программного обеспечения.

Каждая схема аутентификации имеет свои собственные PRO и CON, в зависимости от цели вашей политики безопасности и архитектуры программного обеспечения.

HTTP basic auth over HTTPS

Это первое решение, основанное на стандартном протоколе HTTPS, используется большинством веб-сервисов.

GET /spec.html HTTP/1.1
Host: www.example.org
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Его легко реализовать, доступный по умолчанию во всех браузерах, но имеет некоторые известные недостатки, такие как ужасное окно проверки подлинности, отображаемое в браузере, которое будет сохраняться (здесь нет функции, подобной LogOut), некоторого дополнительного потребления процессора на стороне сервера, и тот факт, что имя пользователя и пароль передаются (через HTTPS) на сервер (он должен быть более безопасным, чтобы пароль оставался только на стороне клиента, во время ввода на клавиатуре и сохранялся как безопасный хэш на сервере) ,

Мы можем использовать Digest Authentication , но для этого требуется HTTPS, так как он уязвим для атак MiM или Replay и специфичен для HTTP.

Сессия через файлы cookie

Честно говоря, сеанс, управляемый на сервере, не является по сути безстоящим.

Одной из возможностей может быть сохранение всех данных в содержимом файла cookie. И, по своему усмотрению, cookie обрабатывается на стороне сервера (клиент, по сути, даже не пытается интерпретировать данные cookie: он просто передает его обратно на сервер при каждом последующем запросе). Но эти данные cookie представляют собой данные состояния приложения, поэтому клиент должен управлять им, а не сервером, в чистом мире без гражданства.

GET /spec.html HTTP/1.1
Host: www.example.org
Cookie: theme=light; sessionToken=abc123

Техника cookie сама по себе связана с HTTP, поэтому она не является действительно RESTful, которая должна быть независимой от протокола, IMHO. Он уязвим для атак MiM или Replay .

Предоставлено через токен (OAuth2)

Альтернативой является размещение маркера в заголовках HTTP, чтобы запрос был аутентифицирован. Это то, что делает OAuth 2.0, например. См. RFC 6749 :

 GET /resource/1 HTTP/1.1
 Host: example.com
 Authorization: Bearer mF_9.B5f-4.1JqM

Короче говоря, это очень похоже на куки-файл и страдает от одних и тех же проблем: а не без гражданства, полагаясь на детали передачи HTTP и подверженные множеству слабых мест безопасности, включая MiM и Replay, поэтому должны использоваться только через HTTPS. Как правило, JWT используется как токен.

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

Аутентификация запроса заключается в подписании каждого запроса RESTful через некоторые дополнительные параметры в URI. См. Эту справочную статью .

В этой статье он был определен как таковой:

Все запросы REST должны быть аутентифицированы путем подписи параметров запроса, отсортированных в нижнем регистре, в алфавитном порядке с использованием личных учетных данных в качестве подписывающего токена. Подписание должно происходить до URL-кодирования строки запроса.

Этот метод, возможно, более совместим с архитектурой Stateless и также может быть реализован с помощью легкого управления сеансом (используя сеансы в памяти вместо сохранения БД).

Например, вот общий образец URI из приведенной выше ссылки:

GET /object?apiKey=Qwerty2010

должны передаваться как таковые:

GET /object?timestamp=1261496500&apiKey=Qwerty2010&signature=abcdef0123456789

Подписанная строка /object?apikey=Qwerty2010&timestamp=1261496500и подпись - это хэш SHA256 этой строки с использованием частного компонента ключа API.

Серверное кэширование данных может быть всегда доступно. Например, в наших рамках мы кэшируем ответы на уровне SQL, а не на уровне URI. Поэтому добавление этого дополнительного параметра не нарушает механизм кэширования.

Подробную информацию об аутентификации RESTful см. В этой статье на нашей платформе ORM / SOA / MVC клиент-сервер на основе JSON и REST. Поскольку мы разрешаем общение не только по HTTP / 1.1, но и по именованным каналам или сообщениям GDI (локально), мы пытались внедрить подлинный шаблон проверки RESTful и не полагаться на специфику HTTP (например, заголовок или куки).

Позже Примечание . Добавление сигнатуры в URI можно рассматривать как плохую практику (поскольку, например, она появится в журналах http-сервера), поэтому ее необходимо смягчить, например, с помощью надлежащего TTL, чтобы избежать повторов. Но если ваши HTTP-журналы скомпрометированы, у вас, безусловно, будут большие проблемы с безопасностью.

На практике ожидаемая аутентификация MAC Tokens для OAuth 2.0 может быть огромным улучшением в отношении текущей схемы «Предоставлено Token». Но это все еще продолжается работа и привязана к передаче HTTP.

Заключение

Стоит заключить, что REST не только HTTP-based, даже если на практике он также в основном реализуется через HTTP. REST может использовать другие уровни связи. Таким образом, аутентификация RESTful - это не просто синоним аутентификации HTTP, независимо от того, что отвечает Google. Он вообще не должен использовать механизм HTTP, но должен быть абстрагирован от уровня связи. И если вы используете HTTP-связь, благодаря инициативе Let's Encrypt нет оснований не использовать надлежащий HTTPS, который требуется в дополнение к любой схеме аутентификации.

Автор: Arnaud Bouchez Размещён: 23.08.2011 09:29

406 плюса

Я сомневаюсь, что люди с энтузиазмом кричали «HTTP-аутентификация», когда-либо пробовали сделать приложение на основе браузера (вместо веб-сервиса от машины к машине) с помощью REST (без обид - я просто не думаю, что они когда-либо сталкивались с осложнениями) ,

Проблемы, которые я обнаружил при использовании HTTP-аутентификации в службах RESTful, которые создают HTML-страницы для просмотра в браузере, следующие:

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

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

Я считаю, что cookie - это решение. Но подождите, печенье злые, не так ли? Нет, они не такие, как часто используются куки, это зло. Сам файл cookie - это всего лишь часть клиентской информации, точно так же, как информация об аутентификации HTTP, которую браузер будет отслеживать во время просмотра. И эта часть клиентской информации отправляется на сервер по каждому запросу, опять же, как и HTTP-аутентификация. Понятно, что единственное отличие состоит в том, что содержимое этой части клиентского состояния может быть определено сервером как часть его ответа.

Создавая сеансы ресурса RESTful, используя только следующие правила:

  • Сессия отображает ключ к идентификатору пользователя (и , возможно, в последнюю экшен-метку времени для тайм - аута)
  • Если сеанс существует, это означает, что ключ действителен.
  • Вход означает POSTing to / sessions, новый ключ устанавливается как файл cookie
  • Выход из системы означает DELETEing / sessions / {key} (с перегруженным POST, помните, что мы браузер, а HTML 5 - еще длинный путь)
  • Аутентификация выполняется путем отправки ключа в виде файла cookie при каждом запросе и проверки наличия и действительности сеанса

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

convert42 добавляет, что при использовании https (что нам нужно) важно, чтобы cookie установил свой безопасный флаг, чтобы информация аутентификации никогда не отправлялась по незащищенному соединению. Отличный момент, сам не видел.

Я считаю, что это достаточное решение, которое прекрасно работает, но я должен признать, что мне недостаточно эксперта по безопасности для выявления потенциальных явлений в этой схеме - все, что я знаю, это то, что сотни веб-приложений, не относящихся к RESTful, используют по существу то же самое протокол входа в систему ($ _SESSION в PHP, HttpSession в Java EE и т. д.). Содержимое заголовка файла cookie просто используется для адресации ресурса на стороне сервера, так же как язык приема может использоваться для доступа к ресурсам перевода и т. Д. Я чувствую, что это то же самое, но, может быть, другие нет? Что вы думаете, ребята?

Автор: skrebbel Размещён: 16.07.2009 07:39

130 плюса

Хватит уже сказано на эту тему хорошими людьми здесь. Но вот мои 2 цента.

Существует два режима взаимодействия:

  1. от человека к машине (HTM)
  2. машина-машина (MTM)

Машина является общим знаменателем, выраженным как API REST, а субъекты / клиенты - это люди или машины.

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

Когда мы рассматриваем это в контексте приложений «от человека к машине», «на основе браузера», как подчеркивает Скреббель, это означает, что (веб-приложение), запущенное в браузере, должно будет отправить свое состояние и соответствующую информацию с каждым запросом он делает API-интерфейсы REST на задней панели.

Рассмотрим это: у вас есть информационная платформа, открытая для активов API REST. Возможно, у вас есть платформа BI для самообслуживания, которая обрабатывает все кубы данных. Но вы хотите, чтобы ваши (человеческие) клиенты получили доступ к этому через (1) веб-приложение, (2) мобильное приложение и (3) какое-то стороннее приложение. В конце концов, даже цепочка MTM ведет к HTM - правильно. Таким образом, человеческие пользователи остаются на вершине информационной цепочки.

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

Понятие аутентификации применяется по всем направлениям. Как вы это разработаете, чтобы ваши API-интерфейсы REST были доступны в едином, защищенном виде? Как я вижу это, есть два способа:

Путь-1:

  1. Для начала нет входа. Каждый запрос выполняет вход в систему
  2. Клиент отправляет свои идентификационные параметры + параметры запроса с каждым запросом
  3. REST API берет их, поворачивает, пингует пользовательское хранилище (что бы это ни было) и подтверждает auth
  4. Если auth установлен, обслуживает запрос; в противном случае отказывается с соответствующим кодом статуса HTTP
  5. Повторите вышеуказанное для каждого запроса по всем API-интерфейсам REST в вашем каталоге

Путь-2:

  1. Клиент начинается с запроса auth
  2. API REST входа в систему будет обрабатывать все такие запросы
  3. Он принимает параметры auth (ключ API, uid / pwd или все, что вы выбираете) и проверяет auth на хранилище пользователей (LDAP, AD или MySQL DB и т. Д.),
  4. Если проверено, создается токен аутентификации и передает его клиенту / вызывающему абоненту
  5. Затем вызывающий абонент отправляет этот токен аутентификации + запрашивает определенные параметры с каждым последующим запросом к другим API-интерфейсам REST для бизнеса, до выхода из системы или до истечения срока аренды

Очевидно, что в Way-2 API REST будет нужен способ распознавания и доверия к токену как действительный. API-интерфейс Login API выполнил проверку подлинности, поэтому для того, чтобы «ключ-ключ» был доверен другим API-интерфейсам REST в вашем каталоге.

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

Но я отвлекся.

Дело в том, что «состояние» (об аутентифицированном статусе клиента) необходимо поддерживать и совместно использовать, чтобы все API REST могли создать круг доверия. Если мы этого не сделаем, это путь-1, мы должны признать, что акт аутентификации должен выполняться для любых / всех входящих запросов.

Выполнение проверки подлинности - это ресурсоемкий процесс. Представьте, что вы выполняете SQL-запросы для каждого входящего запроса в своем хранилище пользователей, чтобы проверить соответствие uid / pwd. Или для шифрования и выполнения хеш-совпадений (стиль AWS). И в архитектуре каждый API REST должен будет выполнить это, я подозреваю, используя общую службу входа в систему. Потому что, если вы этого не сделаете, вы повредите код auth везде. Большой беспорядок.

Так что больше слоев, больше латентности.

Теперь возьмите Way-1 и применитесь к HTM. Ваш пользователь (человек) действительно заботится, если вам нужно отправить uid / pwd / hash или что угодно с каждым запросом? Нет, если вы не беспокоите ее, бросая страницу auth / login каждую секунду. Удачи, если у вас есть клиенты. Итак, что вы будете делать, это хранить информацию для входа где-то на стороне клиента, в браузере, в самом начале и отправлять ее с каждым сделанным запросом. Для пользователя (пользователя) она уже вошла в систему и доступна «сессия». Но на самом деле она аутентифицируется по каждому запросу.

То же самое с Way-2. Ваш (пользователь) пользователь никогда не заметит. Поэтому никакого вреда не было.

Что делать, если мы применим Way-1 к MTM? В этом случае, поскольку его машина, мы можем избавиться от этого парня, попросив его предоставить информацию аутентификации с каждым запросом. Никто не заботится! Выполнение Way-2 на MTM не вызовет никакой особой реакции; его проклятая машина. Это могло бы заботиться меньше!

Так что действительно, вопрос в том, что вам подходит. У безгражданства есть цена, которую нужно заплатить. Оплатите цену и двигайтесь дальше. Если вы хотите быть пуристом, то и заплатите за это тоже, и продолжайте.

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

Автор: Kingz Размещён: 23.11.2013 10:19

48 плюса

Вот действительно и полностью RESTful решение для проверки подлинности:

  1. Создайте пару открытого / закрытого ключей на сервере аутентификации.
  2. Распределите открытый ключ на всех серверах.
  3. Когда клиент аутентифицируется:

    3.1. выдать токен, который содержит следующее:

    • Время истечения
    • имя пользователя (необязательно)
    • пользователи IP (необязательно)
    • хэш пароля (необязательно)

    3.2. Зашифруйте токен с помощью закрытого ключа.

    3.3. Отправлять зашифрованный токен пользователю.

  4. Когда пользователь обращается к любому API, он также должен передать свой токен аутентификации.

  5. Серверы могут проверить, что токен действителен, дешифруя его с помощью открытого ключа сервера auth.

Это аутентификация без аутентификации / RESTful.

Обратите внимание, что если бы хэш-код пароля был включен, пользователь также отправил незашифрованный пароль вместе с токеном аутентификации. Сервер может проверить, соответствует ли пароль паролю, который использовался для создания токена аутентификации, путем сравнения хэшей. Для этого потребуется безопасное соединение с использованием HTTPS. Javascript на стороне клиента может обрабатывать пароль пользователя и сохранять его на стороне клиента, либо в памяти, либо в cookie, возможно, зашифрованном с помощью открытого ключа сервера .

Автор: jcoffland Размещён: 14.10.2013 09:29

35 плюса

Честно говоря, я видел здесь отличные ответы, но что-то, что меня немного беспокоит, - это то, что кто-то полностью примет концепцию безгражданства, где он станет догматичным. Это напоминает мне тех старых поклонников Smalltalk, которые хотели только принять чистое ОО, и если что-то не является объектом, то вы делаете это неправильно. Дайте мне передышку.

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

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

Я открыт для принятия исправлений в комментариях, но я просто не вижу смысла (пока) в том, чтобы сделать нашу жизнь несчастной, чтобы просто не хранить большой словарь хешей на нашем сервере.

Автор: arg20 Размещён: 13.08.2013 08:09

32 плюса

Прежде всего, веб-служба RESTful БЕЗОПАСНО (или, другими словами, БЕСПЛАТНО). Таким образом, служба RESTful не имеет и не должна иметь понятия сеанса или файлов cookie. Способ аутентификации или авторизации в службе RESTful - это использование заголовка HTTP-авторизации, как определено в спецификациях HTTP RFC 2616. Каждый отдельный запрос должен содержать заголовок HTTP-авторизации, и запрос должен быть отправлен по HTTP-соединению (SSL). Это правильный способ сделать аутентификацию и проверить авторизацию запросов в веб-службах HTTP RESTful. Я реализовал веб-службу RESTful для приложения Cisco PRIME Performance Manager в Cisco Systems. И как часть этой веб-службы, я также реализовал аутентификацию / авторизацию.

Рубенс Гомес.

Автор: user2213684 Размещён: 26.03.2013 11:13

22 плюса

Это, конечно, не о «сеансовых ключах», поскольку обычно используется для ссылки на сеансовую аутентификацию, которая выполняется во всех ограничениях REST. Каждый запрос является самоописательным и содержит достаточную информацию для авторизации запроса самостоятельно без какого-либо состояния приложения на стороне сервера.

Самый простой способ приблизиться к этому - начать с встроенных механизмов аутентификации HTTP в RFC 2617 .

Автор: Justin Sheehy Размещён: 26.11.2008 03:06

15 плюса

В «очень проницательной» статье, упомянутой @skrebel ( http://www.berenddeboer.net/rest/authentication.html ), обсуждается запутанный, но действительно сломанный метод аутентификации.

Вы можете попробовать посетить страницу (которая должна быть доступна только для аутентифицированного пользователя) http://www.berenddeboer.net/rest/site/authenticated.html без каких-либо учетных данных.

(Извините, я не могу прокомментировать ответ.)

Я бы сказал, что REST и аутентификация просто не смешиваются. REST означает «без гражданства», но «аутентифицированный» - это состояние. Вы не можете иметь их обоих на одном уровне. Если вы защитник RESTful и нахмурились на государствах, тогда вам нужно пойти с HTTPS (т.е. оставить проблему безопасности на другом уровне).

Автор: Ji Han Размещён: 15.10.2012 07:35

12 плюса

Я думаю, что спокойная аутентификация включает в себя передачу токена аутентификации в качестве параметра в запросе. Примерами являются использование apikeys api's. Я не считаю, что использование файлов cookie или http auth квалифицируется.

Автор: Bjorn Tipling Размещён: 19.01.2009 06:45

9 плюса

Я думаю, что для аутентификации службы REST можно использовать следующий подход:

  1. Создайте API входа RESTful, чтобы принять имя пользователя и пароль для аутентификации. Используйте метод HTTP POST для предотвращения кеширования и SSL для обеспечения безопасности во время транзита. При успешной аутентификации API возвращает два JWT - один токен доступа (более короткая достоверность, скажем, 30 минут) и один токен обновления (более длительный срок действия, например, 24 часа)
  2. Клиент (веб-интерфейс) хранит JWT в локальном хранилище и в каждом последующем вызове API пропускает токен доступа в заголовке «Авторизация: несущий #access»
  3. API проверяет действительность токена, проверяя дату подписи и истечения срока действия. Если токен действителен, проверьте, является ли пользователь (он интерпретирует требование «под» в JWT как имя пользователя) имеет доступ к API с помощью поиска в кеше. Если пользователь имеет право доступа к API, выполните бизнес-логику
  4. Если токен истек, API возвращает код ответа HTTP 400
  5. Клиент, получая 400/401, вызывает еще один REST API с токеном обновления в заголовке «Authorization: Bearer #refresh token», чтобы получить новый токен доступа.
  6. При получении вызова с токеном обновления проверьте, действителен ли токен обновления, проверяя подпись и дату истечения срока действия. Если токен обновления действителен, обновите кэш прав доступа пользователя из БД и верните новый токен доступа и обновите токен. Если токен обновления недействителен, верните код ответа HTTP 400
  7. Если возвращается токен доступа и токен обновления, перейдите к шагу 2. Если возвращается код ответа HTTP 400, клиент предполагает, что токен обновления истек и запрашивает у пользователя имя пользователя и пароль
  8. Для выхода из системы очистите локальное хранилище

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

Автор: Saptarshi Basu Размещён: 14.01.2017 01:30

7 плюса

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

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

Автор: moshe beeri Размещён: 08.12.2011 10:44

1 плюс

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

Система проверки подлинности, использующая 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-методов, сопоставленных с их базой данных, а затем создания системы аутентификации с учетом того, что вам не нужно проходить сеансы идентификаторов сеансов или треков.

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

Автор: mike Размещён: 19.01.2009 06:14

1 плюс

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

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

Автор: DonB. Размещён: 02.11.2013 04:08

0 плюса

Ответил в октябре 2018 года

Советы, необходимые для защиты любого веб-приложения

Если вы хотите защитить ваше приложение, то вам обязательно нужно начать с 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

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

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

Вы можете узнать больше о JWTs по этой ссылке

Автор: Ahmed Elkoussy Размещён: 15.10.2018 06:16
Вопросы из категории :
32x32