Предварительное собеседование для проверки и заполнения вакансий -- (10) Передняя аутентификация

опрос
Предварительное собеседование для проверки и заполнения вакансий -- (10) Передняя аутентификация

предисловие

Эта серия изначально была подготовлена ​​для моего собственного интервью, потом я обнаружил, что сортировок становится все больше и больше, почти 120 000 символов, и, наконец, решил поделиться со всеми.

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

Ссылка на статью

Коллекция:

Предварительные собеседования для проверки пропусков и заполнения вакансий — индекс (набор из 120 000 слов)Содержит более дюжины других статей из серии, которые были написаны до сих пор.Последующие новые статьи с добавленной стоимостью больше не будут добавлять ссылки на каждую статью.Настоятельно рекомендуется ставить лайк и следить за коллекцией!!!!, спасибо!~

Последующий план обновления

Будет продолжать добавлять в будущемШаблоны проектирования,Фронтенд-инжиниринг,процесс проекта, развертывание, замкнутый цикл,Vue часто проверяет очки знанийДождитесь контента. Если вы считаете, что контент хорош, добро пожаловать, собирайте и подписывайтесь на меня! Спасибо!

Спросите инсайдера

В настоящее время я тоже готовлюсь к смене работы, надеюсь, вы и HR дамы порекомендуете надежную.УханьФронтальный пост! Электронная почта: bupabuku@foxmail.com. Спасибо!~

Общие методы аутентификации

В настоящее время мы обычно используем четыре типа аутентификации:

  1. Базовая HTTP-аутентификация
  2. session-cookie
  3. Проверка токена (включая JWT, SSO)
  4. OAuth (открытая авторизация)

HTTP Basic Authentication

Этот метод аутентификации является основным методом авторизации, реализуемым браузером в соответствии с протоколом HTTP.В процессе связи по протоколу HTTP протокол HTTP определяет базовый метод аутентификации, позволяющий HTTP-серверу выполнять идентификационную карту пользователя на клиенте. .

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

Процесс проверки кратко упоминается здесь, в основном см.статья

Процесс сертификации:1. Клиент запрашивает данные с сервера. Запрашиваемый контент может быть веб-страницей или асинхронным запросом ajax. В это время, предполагая, что клиент не прошел аутентификацию, клиент отправляет на сервер следующий запрос:

  Get /index.html HTTP/1.0 
  Host:www.google.com

2.Сервер отправляет код запроса аутентификации 401 клиенту, (WWW-Authenticate: Basic realm=”google.com”Эта фраза ключевая, если нет клиента не будетВсплывающий интерфейс ввода имени пользователя и пароля) Данные, возвращаемые сервером, примерно следующие:

  HTTP/1.0 401 Unauthorised 
  Server: SokEvo/1.0 
  WWW-Authenticate: Basic realm=”google.com” 
  Content-Type: text/html 
  Content-Length: xxx

3.当符合http1.0或1.1规范的客户端（如IE，FIREFOX）收到401返回值时，将自动弹出一个登录窗口，要求用户输入用户名和密码。

4. После того, как пользователь введет имя пользователя и пароль,Имя пользователя и пароль зашифрованы с помощью шифрования BASE64 (base64 небезопасен!), и поместите зашифрованный текст в предыдущее сообщение запроса, первое сообщение запроса, отправленное клиентом, станет следующим:

  Get /index.html HTTP/1.0 
  Host:www.google.com 
  Authorization: Basic d2FuZzp3YW5n

Примечание: d2FuZzp3YW5n представляет зашифрованные имя пользователя и пароль (имя пользователя: пароль, а затем зашифрованное с помощью base64, процесс шифрования — это поведение браузера по умолчанию, нам не нужно искусственное шифрование, нам нужно только ввести имя пользователя и пароль)

5. После получения вышеуказанной информации запроса сервер извлекает и расшифровывает информацию о пользователе в поле Авторизация и сравнивает расшифрованные имя пользователя и пароль с базой данных пользователей для проверки.Если имя пользователя и пароль верны, сервер отправляет запрошенный ресурс в соответствии с запросом, отправленным клиенту

Эффект:
Когда клиент не аутентифицирован, появится окно ввода имени пользователя и пароля.В это время запрос находится в состоянии ожидания.В это время, фактически, когда пользователь вводит имя пользователя и пароль, клиент снова отправит запрос с заголовком Authentication.

session-cookie

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

Процесс сертификации:

1. Сервер создает сеанс на стороне сервера, когда он принимает первый доступ с клиента, а затем сохраняет сеанс (мы можем сохранить сеанс в памяти или в Redis, второй рекомендуется), а затем генерируют уникальный сеанс Для этого сеанса. Идентификационная строка, а затем семянная строка уникальной идентификации в заголовке ответа.

2. Подпишите. На этом этапе просто зашифровывается SID, и сервер будет расшифровывать его в соответствии с этим секретным ключом. (Необязательные шаги)

3. Когда браузер получает ответ на запрос, он анализирует заголовок ответа, а затем сохраняет sid в локальном файле cookie.Браузер перенесет информацию о файле cookie под доменным именем в заголовок запроса следующего http-запроса.

4. Когда сервер примет запрос клиента, он проанализирует sid в файле cookie заголовка запроса, а затем найдет сохраненную сервером сессию клиента в соответствии с sid, а затем решит, является ли запрос законным.

Недостатки:

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

Проверка токена

концепция

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

Простейший состав токена: uid (уникальный идентификатор пользователя), time (отметка времени текущего времени), sign (подпись, которая сжимается до определенной длины шестнадцатеричных символов по первым нескольким цифрам токена + соль со строкой алгоритма хеширования , что может помешать злонамеренным третьим сторонам сплайсировать запросы токенов на сервер). Вы также можете поместить в токен неизменяемые параметры, чтобы избежать многократного поиска в базе данных.

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

процесс проверки

Примерный процесс выглядит следующим образом:

  • 1, клиент использует имя пользователя и пароль для запроса входа в систему
  • 2, сервер получает запрос на проверку имени пользователя и пароля
  • 3. После успешной проверки сервер выдаст Токен, а затем отправит Токен клиенту.
  • 4. После того, как клиент получит токен, его можно сохранить, например, в файле cookie или локальном хранилище.
  • 5. Клиенту необходимо приносить Токен, выданный сервером, каждый раз, когда он запрашивает ресурсы с сервера.
  • 6. Сервер получает запрос, а затем проверяет токен, переданный в клиентском запросе.Если проверка прошла успешно, он возвращает запрошенные данные клиенту.

В общем, после первого входа клиента, когда сервер снова получает http-запрос, он распознает только токен.Запросу нужно только приносить токен каждый раз.Сервер будет перехватывать все запросы, а затем проверять токен , законность, законность выпущена,Верните 401, если это незаконно(Аутентификация не удалась).

Преимущества и недостатки токенов

преимущество:

  • Токен полностью управляется приложением, поэтому оно может избежать политики одного и того же происхождения (файлы cookie не разрешают доступ с неработающих доменов, а токен не существует).
  • Токен может избежать атак CSRF (также потому, что файлы cookie не нужны)
  • Токены могут не иметь состояния и могут использоваться несколькими службами.
  • Токен поддерживает доступ к мобильному терминалу (Cookie не поддерживает доступ к мобильному терминалу)

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

недостаток:

  • Занятая полоса пропускания: в обычных условиях токен больше, чем session_id, который должен потреблять больше трафика и занимать больше полосы пропускания (но его можно практически игнорировать).
  • Проблема с производительностью: по сравнению с сеансовым файлом cookie, токен требует больше времени и производительности на стороне сервера для расшифровки и проверки токена. Фактически, по сравнению с сеансовым файлом cookie, токен представляет собой решение «время для места».

Разница между токеном и сеансом

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

  • 2. Токену не нужно использовать файлы cookie.Сеанс-куки требует сотрудничества с куки, поэтому выбор http-прокси-клиента остается только за браузером, потому что только браузер будет анализировать куки в заголовке ответа на запрос, и тогда каждый запрос по умолчанию будет приноситься под доменным именем. . Но мы то знаем, что http прокси-клиент - это не только браузер, но и родной APP и т.д. В это время куки не работают, либо браузер может запретить куки (хотя это возможно, но это в принципе еда Человек, который это сделал), но токен другой. Это информация, возвращаемая в теле ответа после успешного входа в систему. Когда клиент получает ответ, он может сохранить его в локальном файле cookie, хранилище, Или в памяти, и тогда заголовок следующего запроса снова активирует этот токен. Проще говоря, механизм сеанса cookie ограничивает типы клиентов, а механизм проверки токена обогащает типы клиентов.

  • 3. Своевременность. Идентификатор сеанса файла cookie сеанса фактически генерируется при входе в систему и остается неизменным при выходе из системы, поэтому безопасность будет в определенной степени низкой, а токен может динамически изменяться в течение определенного периода времени.

  • 4. Масштабируемость. Сама по себе верификация токенов относительно гибка: во-первых, существует множество решений для токенов, широко используется JWT, во-вторых, мы можем сделать сервис аутентификации на основе механизма верификации токенов и использовать его для выполнения унифицированной аутентификации по запросам от нескольких сервисов. .

Срок действия токена и токен обновления

Срок действия токена истек:

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

Refresh Token :

Зачем нужен токен обновления?

Если срок действия токена истек, его необходимо получить повторно. Продолжайте повторять процесс получения токена в первый раз (например, вход в систему, авторизация сканирования и т. д.), и вы должны получать его каждый час! Это очень плохой пользовательский опыт. Чтобы решить эту проблему, существует токен обновления.Повторно получите новый токен через токен обновления.

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

JWT (JSON Web Tokens)

Статья учителя Руан Ифэн о JWT, Это действительно хорошо написано, и многие люди цитировали и цитировали его. Студенты, которые не знают JWT, могут напрямую проверить эту статью, я не буду копировать ее здесь. Здесь я сосредоточусь только на подведении итогов.

Принцип JWT

Принцип JWT заключается в том, что после аутентификации сервера объект JSON генерируется и отправляется обратно пользователю. Когда пользователь связывается с сервером, сервер только зависит от этого объекта для идентификации идентификации пользователя. Чтобы предотвратить попадание пользователей с данными, когда сервер генерирует этот объект,будет подписано.

Самая большая особенность jwt:Сервер не сохраняет никаких данных сеанса, то есть сервер становится апатридом, что упрощает реализацию расширения.

Структура данных JWT

это долгонить, разделенных на три части точкой (.) посередине.

Это: Header (заголовок). Payload (загрузка). Signature (подпись).

  • Header :Раздел представляет собой объект JSON, описывающий метаданные JWT, например:{ "alg": "HS256","typ": "JWT"}Атрибут .alg указывает алгоритм подписи.По умолчанию используется HMAC SHA256 (записывается как HS256), атрибут typ указывает тип токена (type), а токен JWT единообразно записывается как JWT.

Объект JSON в заголовке преобразуется в строку с использованием алгоритма Base64URL.

  • Payload:Раздел также является объектом JSON, который используется для хранения фактических данных, которые необходимо передать. Этот объект JSON также преобразуется в строку с использованием алгоритма Base64URL.

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

  • Signature:часть является подписью к первым двум частям,Предотвратить подделку данных.Во-первых, вам нужно указать секрет. этот ключТолько сервер знает и не может быть раскрыт пользователю. Затем используйте алгоритм подписи, указанный в заголовке (по умолчанию HMAC SHA256).

Несколько характеристик JWT

  • (1) JWT по умолчанию не зашифрован, но его можно зашифровать. После создания исходного токена вы можете зашифровать его еще раз.
  • (2) Если JWT не зашифрован, секретные данные не могут быть записаны в JWT.
  • (3) JWT можно использовать не только для аутентификации, но и для обмена информацией. Эффективное использование JWT может сократить количество запросов сервера к базе данных.
  • (4) Самый большой недостаток JWT заключается в том, чтоПоскольку сервер не сохраняет состояние сеанса, невозможно отозвать токен во время использования или изменить разрешения токена. То есть после выдачи JWT он останется действительным до истечения срока его действия, если только сервер не развернет дополнительную логику.
  • (5) Сам JWT содержит информацию об аутентификации, и после ее утечки любой может получить все разрешения токена. Чтобы уменьшить незаконное присвоение, JСрок действия WT должен быть установлен относительно коротким.Для некоторых более важных разрешений пользователи должны пройти повторную аутентификацию при их использовании.
  • (6) Чтобы уменьшить незаконное присвоение, JWT не должен передаваться в виде простого текста с использованием протокола HTTP, а должен передаваться с использованием протокола HTTPS.

При первом входе в систему после определения правильности пароля учетной записи пользователя внутренний сервер создает токен в соответствии с идентификатором пользователя, именем пользователя, определенным секретным ключом и временем истечения срока действия и возвращает его на внешний сервер. конец; Внешний интерфейс получает токен, возвращенный серверной частью, и сохраняет его в localStroage и Vuex; Каждый раз при маршрутизации внешнего интерфейса оценивается, есть ли у localStroage токен, если нет, то он переходит на страницу входа в систему, а если есть, то запрашивает получение информации о пользователе и изменение статуса входа; Каждый раз, когда запрашивается интерфейс, токен передается в заголовке запроса Axios; Внутренний интерфейс оценивает, есть ли токен в заголовке запроса, нет или срок действия токена истек, и возвращает 401; Внешний интерфейс получает код состояния 401 и перенаправляет на страницу входа.

Дополнение: метод для бэкэнда, чтобы активно аннулировать JWT.

Как упоминалось ранее, после выпуска JWT он больше не будет контролироваться сервером.Поскольку он не записан на сервере, он не имеет состояния, что является его самым большим преимуществом и самым большим недостатком.Это приведет к своего рода неуправляемости.

Например: если пользователь модифицирует, как может быть отброшен токен, срок действия которого не истек??? В это время на сервере нет записи, и он не знает, какие токены, срок действия которых не истек, были отброшены. решить эту проблему, на самом делеИдеального метода нет!Оба требуют, чтобы серверная часть добавляла состояние, но этот метод имеет наименьшие накладные расходы.

Наиболее распространенными методами лечения являются:

  • 1, токен хранится в БД (например, redis), сбой удаляется; но добавляет проверку каждый шаг времени должен начать с запроса DB, есть ли токен, и вопреки принципу не состоятельного JWT (не рекомендуется не рекомендуется ).
  • 3. Добавьте поле номера версии в JWT, чтобы изменить номер версии.
  • 4. При установке зашифрованного ключа на сервере для каждого пользователя генерируется уникальный ключ, и в случае неудачи ключ меняется.

Вот краткое введение во второй метод: черный список

  • 1. Добавить поле случайных символов в полезную нагрузку в выданном jwttoken_id.
  • 2. Сохраните черный список «groupId» в распределенном кеше сервера. Если для сброса пароля jwt пользователя и т. д. необходимо аннулировать jwt, срок действия которого не истек, «token__id» предыдущего пользователя будет сохранен в черном списке. и назначьте ему новый «token__id» в токен.
  • 3. «token__id», хранящийся в черном списке, устанавливает время истечения срока действия, после которого «token_id» автоматически удаляется из черного списка.
  • 4, все должны сделать JWT проверять действительность сервера, доступа к распределенному кеше при запуске. Черный список загружается в локальную память. И подпишитесь на распределенный кэш-сообщение Push Push-функции, дополнения и удаления возникают во время черного списка, получают синхронизацию Push-сообщения Изменить память BlackList.
  • 5. Когда сервер выполняет проверку JWT, помимо проверки времени истечения срока действия, он также запрашивает черный список в памяти. Если он находится в черном списке, JWT считается недействительным.

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

войти

концепция

Единый вход (Single Sign On), называемый SSO, является одним из наиболее популярных решений для корпоративной бизнес-интеграции. Определение SSO находится в системах с несколькими приложениями,Пользователям нужно войти в систему только один раз, чтобы получить доступ ко всем взаимно доверенным системам приложений.

Для SSO обычно требуется независимый центр аутентификации (паспорт). Вход в подсистемы должен проходить через паспорт. Сама подсистема не будет участвовать в операции входа. При успешном входе в систему паспорт выдает токен для каждой подсистемы. , Подсистемы могут хранить токены для получения своих собственных защищенных ресурсов.Чтобы уменьшить частоту аутентификации, каждая подсистема будет устанавливать локальный сеанс после авторизации по паспорту, и нет необходимости снова инициировать аутентификацию по паспорту в течение определенного периода времени.

Процесс единого входа

  • Пользователь обращается к защищенным ресурсам системы 1, а система 1 обнаруживает, что пользователь не вошел в систему, переходит к центру аутентификации sso и использует собственный адрес в качестве параметра
  • Центр аутентификации sso обнаруживает, что пользователь не вошел в систему, и направляет пользователя на страницу входа.
  • Пользователь вводит имя пользователя и пароль для подачи заявки на вход
  • Центр аутентификации sso проверяет информацию о пользователе, создает сеанс между пользователем и центром аутентификации sso, называемый глобальным сеансом, и одновременно создает токен авторизации.
  • Центр аутентификации sso отправляет токен на начальный адрес запроса (система 1).
  • Система 1 получает токен и обращается в центр аутентификации sso, чтобы проверить, действителен ли токен.
  • Центр аутентификации SSO проверяет токен, возвращает действительный и регистрирует систему 1.
  • Система 1 использует этот токен для создания сеанса с пользователем, называемого частичным сеансом, возвращая защищенный ресурс.
  • Пользователь получает доступ к защищенным ресурсам Системы 2
  • Система 2 обнаруживает, что пользователь не вошел в систему, переходит к центру аутентификации sso и использует собственный адрес в качестве параметра.
  • Центр аутентификации sso обнаруживает, что пользователь вошел в систему, возвращается к адресу системы 2 и прикрепляет токен.
  • Система 2 получает токен и обращается в центр аутентификации sso, чтобы проверить, действителен ли токен.
  • Центр аутентификации sso проверяет токен, возвращает действительный и регистрирует систему 2.
  • 2 Система использует токен для создания сеанса локального пользователя с возвратом защищенных ресурсов

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

  • Локальный сеанс существует, глобальный сеанс должен существовать
  • Глобальная сессия существует, но локальная сессия не обязательно существует
  • Глобальная сессия уничтожена, локальная сессия должна быть уничтожена

Выйти:

Центр аутентификации SSO контролировал статус глобальной сессии. После уничтожения глобальной сессии слушатель уведомляет всех систем регистрации для выполнения операции выхода из системы.

  • Пользователь инициирует запрос на выход из системы 1.
  • Система 1 получает токен в соответствии с идентификатором сеанса, установленным пользователем и системой 1, и инициирует запрос на выход из системы в центр аутентификации sso.
  • Центр аутентификации sso проверяет допустимость токена, уничтожает глобальный сеанс и удаляет все системные адреса, зарегистрированные с этим токеном.
  • Центр сертификации SSO инициирует запрос на выход из системы во все системы регистрации.
  • Каждая система регистрации получает запрос на выход из центра аутентификации sso и уничтожает локальную сессию.
  • Центр аутентификации SSO направляет пользователя на страницу входа

OAuth 2.0

OAuth — это авторизация разработки, которая на самом деле похожа на SSO.Он позволяет пользователям разрешать сторонним веб-сайтам получать доступ к своей информации, хранящейся у другого поставщика услуг, без необходимости предоставлять имена пользователей и пароли сторонним веб-сайтам или делиться всеми своими данными, в Чтобы защитить безопасность и конфиденциальность пользовательских данных, сторонние веб-сайты должны явно запрашивать у пользователей авторизацию перед доступом к пользовательским данным. Среди наших общих поставщиков, которые предоставляют услуги аутентификации OAuth, QQ, WeChat, Weibo и т. д.

Из-за нехватки места здесь рекомендация по-прежнему принадлежит учителю Руань Ифэн.статья

спасибо и ссылка

Категории