it-roy-ru.com

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

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

710
Jim Keener

Как обрабатывать аутентификацию в RESTful клиент-серверной архитектуре - вопрос спорный.

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

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

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

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

Базовая аутентификация HTTP через 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

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

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

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

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

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

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

Например, вот пример общего 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 (например, заголовок или файлы cookie) ,.

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

На практике предстоящая Аутентификация по токенам MAC для OAuth 2. может значительно улучшить текущую схему "Предоставлено токеном". Но это все еще в стадии разработки и связано с передачей HTTP.

Заключение

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

556
Arnaud Bouchez

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

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

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

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

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

Делая сессии RESTful-ресурсом только со следующими правилами:

  • A session maps a key to a user id (and possibly a last-action-timestamp for timeouts)
  • Если сеанс существует, то это означает, что ключ действителен.
  • Вход в систему означает POSTing для/сессий, новый ключ устанавливается как cookie
  • Выход из системы означает УДАЛЕНИЕ/сессий/{ключ} (помните, что при перегруженном POST мы браузер, а HTML 5 еще долгий путь)
  • Аутентификация выполняется путем отправки ключа в виде куки-файла при каждом запросе и проверки, существует ли сеанс и является ли он действительным

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

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

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

412
skrebbel

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

Есть 2 режима взаимодействия:

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

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

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

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

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

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

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

Путь-1:

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

Путь-2:

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

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

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

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

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

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

Чем больше слоев, тем больше задержка.

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

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

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

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

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

135
Kingz

Вот подлинно и полностью RESTful решение для аутентификации:

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

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

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

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

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

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

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

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

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

51
jcoffland

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

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

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

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

36
arg20

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

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

32
user2213684

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

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

22
Justin Sheehy

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

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

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

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

15
Ji Han

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

12
Bjorn Tipling

Обновление от 16 февраля 2019 г.

Подход, упомянутый ранее ниже, по существу является типом предоставления "Учетные данные пароля владельца ресурса" OAuth2. . Это простой способ начать работу. Однако при таком подходе каждое приложение в организации будет иметь собственные механизмы аутентификации и авторизации. Рекомендуемый подход - тип предоставления "Код авторизации". Кроме того, в моем предыдущем ответе ниже я рекомендовал браузер localStorage для хранения токенов авторизации. Тем не менее, я пришел к выводу, что cookie является правильным вариантом для этой цели. Я подробно изложил свои причины, подход к реализации типа предоставления кода авторизации, соображения безопасности и т.д. В этот ответ StackOverflow .


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

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

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

12
Saptarshi Basu

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

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

8
moshe beeri

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

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

2
DonB.

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

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

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

2
mike

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

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

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

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

0
Ahmed Elkoussy