[МУЗЫКА]
В предыдущих уроках
мы видели несколько различных типов схем аутентификации.
Мы начали с обычной аутентификации, затем мы посмотрели, как мы можем использовать файлы cookie для
аутентификации и даже подписанные файлы cookie, а
затем мы рассмотрели аутентификацию на основе сеанса.
Где сервер отслеживает информацию о каждом клиенте, а
затем cookie будет использоваться как способ индексирования в серверную
базу данных для извлечения дополнительной информации, для проверки пользователя.
Теперь файлы cookie и сеансовые проверки подлинности не масштабируются,
потому что сервер должен отслеживать всех разных пользователей.
Несмотря на то, что это делается вне самого протокола HTTP, но
все же тот факт, что вам нужно отслеживать
всю информацию раздела сайта сервера, делает его не очень масштабируемым.
Таким образом, здесь аутентификация на основе токенов
оказалась очень полезной.
мы рассмотрим аутентификацию на базе токенов немного более подробно в этой лекции и
упражнении, которое следует за этим.
Опять же, быстро просматривая файлы cookie и аутентификацию на основе сеанса.
При аутентификации на основе файлов cookie
мы замечаем, что файлы cookie хранятся на стороне клиента, а файлы cookie включаются
в каждое исходящее сообщение запроса, в результате чего сервер получает напоминание об
этом конкретном клиенте, извлекая информацию из файла cookie.
Cookie можно использовать вместе с сеансами, в результате чего файлы cookie сохраняют идентификатор сеанса,
а затем, когда сервер получает входящий запрос от файла cookie,
он извлекает идентификатор сеанса и использует его в качестве индекса в
хранилище сеансов на стороне сервера для получения информации о сеансе конкретного клиента.
Теперь, этот подход, как я уже сказал,
не очень масштабируемый, потому что если у вас есть тысячи сеансов, сервер должен
отслеживать все эти тысячи сеансов на стороне сервера.
Несмотря на то, что это делается независимо от HTTP в хранилище,
либо в хранилище файлов, либо в базе данных.
Но все же
тот факт, что вам нужно отслеживать всю эту информацию, делает ее немасштабируемой.
Итак, опять же, чтобы напомнить вам еще раз,
почему мы говорим об аутентификации на основе токенов?
Сеансионная аутентификация, как мы уже видели ранее, отлично работает для
веб-приложений и может легко позаботиться о аутентификации пользователей.
Но затем аутентификация на основе сеанса, хотя это принцип
серверов без гражданства, а также приводит к проблемам масштабируемости.
Вторая проблема заключается в том, что мобильные приложения не
очень хорошо обрабатывают сеансовую аутентификацию.
Аналогичным образом, мобильные приложения испытывают трудности, связанные с файлами cookie.
Итак, в таких условиях, когда ваш сервер обслуживает данные
как для веб-приложения, так и для мобильного приложения.
Затем аутентификация на основе сеанса не будет очень полезной, и
именно здесь аутентификация на основе токенов становится намного более простой в использовании.
В аутентификации на основе токенов в качестве имени
на месте сервер выдает токен проверенному пользователю, и все последующие
запросы, поступающие со стороны клиента, будут нести токен в самом запросе.
Либо в виде заголовка запроса, либо в теле сообщения запроса.
Кроме того, аутентификация на основе токенов также помогает нам
справиться с так называемыми проблемами CORS или CSRF.
Проблемы с распределением ресурсов между происхождением и так
далее, я кратко расскажу о стоимости в следующем модуле.
Но на данный момент аутентификация на основе токенов решает некоторые проблемы
, связанные с автомобилями и проблемами, связанными с подделкой межсайтовых запросов.
Мало того, что аутентификация на основе токенов намного проще для
одного приложения, чтобы поделиться своей аутентификацией с другим приложением.
Конечно, все это делается безопасным образом.
Но, с аутентификацией на основе сеанса, это не просто.
Как работает аутентификация на основе токенов?
При аутентификации на основе токенов
пользователь сначала должен проверить себя на стороне сервера.
Теперь эта проверка может принимать формы, которые мы видели ранее.
Таким образом, мы можем использовать локальную проверку, используя имя пользователя и пароль.
Или мы можем даже использовать проверку третьей стороны, используя
такие технологии, как oauth или oauth 2.0 или open ID.
Мы кратко поговорим о oauth и oauth 2.0 в следующем модуле.
Но, независимо от того, каким образом пользователь аутентифицируется,
после того, как пользователь аутентифицирован, ваш сервер может просто выдать токен пользователю.
И все последующие связи между пользователем и
сервером, можно сделать просто с помощью этого токена.
JSON Web Token, о котором мы будем говорить, является одной из таких
схем аутентификации на основе токенов, и там сервер, когда он создает этот токен, он создаст подписанный токен.
Использование секрета на сайте сервера, который знает только сервер.
Таким образом, даже если третья сторона в сторону и между и
пытается манипулировать токеном, даже если он захватывает токен и
пытается манипулировать токеном, токен станет недействительным.
И поэтому, такой способ защиты пользователя
легко осуществим, все последующие запросы
со стороны клиента должны нести токен в запросе,
либо, как я уже сказал, в заголовке или в теле сообщения запроса.
Поэтому, когда сервер получает этот токен, сервер проверит токен,
чтобы убедиться, что это действительный токен, а затем, если он является допустимым токеном,
сервер ответит на входящий запрос.
Как я уже упоминал, JSON Web Tokens является одной из таких схем аутентификации на основе токенов.
JSON Web Token - это очень простой способ кодирования
информации в токене, а затем передать его на сайт клиента.
Сам JSON Web Token основан на стандартах,
это основано на IETF RFC 7519.
IETF здесь, выступает за Инженерную группу Интернета.
Организация, которая поручает все о том, как работает Интернет,
и имеет дело с протоколами и политиками, связанными с Интернетом.
RFC означает документ о стандартах,
в терминах IETF RFC означает запрос на комментарии.
И каждый такой нормативный документ несет в себе ряд.
7519 в этом случае относится к документу,
стандартному документу, связанному с JSON Web Token.
Сам JSON Web Token является автономным токеном, он несет всю
информацию внутри себя, что необходимо для идентификации пользователя.
Мало того, что JSON Web Token можно разделить между двумя приложениями.
Так, например, одно приложение, когда оно аутентифицируется, а затем получает
JSON Web Token, может передать этот JSON Web Token и в этом приложении,
что оно готово разрешить доступ к серверу от его имени.
Этот обмен токеном делается очень безопасным образом,
поэтому не беспокойтесь слишком много о безопасности там.
Это не безопасно,
где путем совместного использования токена между одним приложением другому.
Таким образом, авторизация передается второму приложению, а
второе приложение может авторизоваться от имени первого приложения
для связи с сервером.
Это возможно с токенами.
Теперь, конечно, инженер в вас, очевидно, будет интересно, что именно находится
внутри JSON Web Token, и как это полезно?
JSON Web Token, как я уже сказал, кодируется в длинную строку, и
сама эта строка может быть интерпретирована как состоящая из трех частей.
Сама строка может, или сама закодированная строка содержит три части:
Заголовок, Полезная нагрузка и Подпись.
Это несет достаточно информации о том, как кодируется этот токен.
Сам заголовок содержит конкретный алгоритм, который используется для
кодирования этого JSON Web Token, и тип самого маркера.
Алгоритм в этом случае будет HS256, который представляет собой 256-битную схему кодирования,
которая используется для хеширования информации внутри токена.
И в этом случае это JSON Web Token, и поэтому
поле типа будет установлено в JWT.
И так это информация, которая хранится в заголовке JSON Web Token. Сама
полезная нагрузка, несет в себе информацию, которая поможет вам идентифицировать пользователя.
В упражнении, которое мы сделаем,
часовая полезная нагрузка несет только идентификатор пользователя внутри полезной нагрузки.
Никакой другой информации не требуется.
Этот идентификатор может быть использован на стороне сервера,
чтобы индексировать в Mongo DB, чтобы получить полную информацию о пользователе, если это необходимо.
Итак, вы увидите, что мы кодируем идентификатор, а
затем сохраним его в полезной нагрузке этого сообщения.
При необходимости можно хранить дополнительную информацию в полезной нагрузке сообщения.
Но чем больше информации, которую вы сохранили там,
тем больше соответствующий JSON Web Token будет мне.
Таким образом, попробуйте ограничить объем информации, которую вы сохранили в полезной нагрузке
JSON Web Token.
Как мы увидим в упражнении, у нас есть модуль узла, который позволяет нам
кодировать и создавать JSON Web Token,
на основе информации, которую мы хотим поместить в полезную нагрузку.
Теперь, когда вы создаете JSON Web Token, вы также предоставляете подпись.
Секретный ключ на стороне сервера, который используется для кодирования этого JSON Web Token,
и этот секрет также включен в подписную часть JSON Web Token.
Сама подпись включена таким образом, что
перед закодированным заголовком и полезной нагрузкой есть основы,
которые затем кодируются с использованием конкретного секрета, который используется сервером.
И это закодировано, как я сказал HMAC,
что мы упоминали в одном из предыдущих уроков и
используя 256-битное хэширование, и это включено в подпись.
Итак, когда этот JSON Web Token получен на стороне сервера, и
когда сервер декодирует этот токен, сервер может перекрестно проверить,
чтобы убедиться, что этот JSON Web Token не был изменен кем-либо,
в то время как токен передается между клиентом и сайтом сервера.
Поэтому, если вы знаете что-нибудь о безопасности, злоумышленниках
и так далее, вы понимаете, почему важно кодировать токен и
проверить подлинность токена на сайте сервера.
Как я уже упоминал, если вам нужно иметь дело с JSON Web Tokens в вашем приложении узла.
Существует конкретный модуль узла, называемый как модуль узла jsonwebtoken.
Этот модуль узла реализует стандарты, связанные с JSON Web Token, и
он может быть включен в ваше приложение узла.
Этот модуль сам предоставляет метод, называемый знаком, который позволяет подписывать и
выдавать токен клиенту со стороны сервера.
Он также содержит метод проверки.
Который может быть использован для проверки подлинности или
для обеспечения подлинности входящего JSON Web токена,
поэтому мы будем использовать модуль JSON Web токена, в нашем упражнении.
Вместе с модулем JSON Web Token
мы также использовали модуль Passport-JWT, модуль узла.
Что обеспечивает стратегии на основе jwt для нашего модуля аутентификации паспортов.
Таким образом, это обеспечивает паспортную стратегию для аутентификации с помощью JSON Web Token.
Таким образом, это позволяет вам аутентифицировать конечную точку RESTful, используя JWT в качестве
метода для проверки, не требуя, чтобы сервер использовал сеансы.
Теперь модуль паспорта JWT
поддерживает метод даже извлечения токена JWT из
входящего сообщения запроса, а затем даже проверки токена от вашего имени.
Интерн модуля Passport-JWT, использует модуль JSON Web Token для
проверки этого JSON Web Token.
Сам токен может быть перенесен в заголовок входящего запроса,
в заголовок, даже в заголовке аутентификации входящего запроса,
что и будет делать в упражнении.
Токен также может быть перенесен в тело входящего запроса, и в этом случае
мы должны извлечь токен из тела входящего запроса, а
затем использовать его.
Модуль Passport-JWT поддерживает это также, если вы решите
использовать его как способ передачи токена обратно от клиента на сайт сервера.
JSON Web Token, также может быть включен в параметры запроса URL, если вы так
решили, и может быть извлечен из него b Passport-JWT и
использован для аутентификации.
Теперь, с этим быстрым пониманием JSON Web Token и
как они полезны, мы перейдем к упражнению, где мы будем использовать
модуль Passport-JWT вместе с модулем JSON Web Token
и настроить наш сервер Express Rest API для использования JSON Web Token.
[ МУЗЫКА]