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

Под аутентификацией (Аутентификацией) в сфере информационной безопасности понимается процесс идентификации и подтверждения подлинности права личности, заявленного декларантом.

В области ИТ: проверьте легитимность и действительность сеансов, файлов cookie и токенов.

1. HTTP-аутентификация

Позволяет клиенту проверять личность пользователя с помощью имени пользователя и пароля при запросе.

⚠️Примечание: почти все веб-сайты не будут использовать эту схему сертификации, просто взгляните

процесс

  1. Клиент запрашивает ограниченные данные с сервера
  2. сервер возвращает HTTP/401 Unauthorized
  3. Клиент всплывает, чтобы спросить пользователя
  4. Клиент снова отправляет запрос на сервер с именем пользователя и паролем в формате Base64.
  5. авторизация на стороне сервера
  6. Если проверка прошла успешно, сервер вернет клиенту код состояния 200 (или, если проверка не пройдена, вернет клиенту код состояния 403).

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

  • Простая, базовая поддержка браузеров

Недостатки

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

сцены, которые будут использоваться

  • внутренняя сеть
  • Сети с низкими требованиями к безопасности

2. Аутентификация Session-Cookie

Аутентификация Session-Cookie — это внешний и внутренний режим аутентификации связи, реализованный с использованием файлов cookie сеанса сервера (сеанса) и браузера (клиента).

Что такое файлы cookie?

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

Возможности:

  1. Файлы cookie хранятся на стороне клиента и могут быть изменены по желанию, что небезопасно.
  2. up to 4kb
  3. Существует ограничение на количество файлов cookie. Для веб-сайта может храниться не более 20 файлов cookie, а браузер обычно может хранить 300 файлов cookie.
  4. Файлы cookie не являются междоменными, но доменное имя первого уровня и доменное имя второго уровня могут быть общими (домен)

Что такое Сессия?

Абстрактное понятие сеанса — это сеанс, который представляет собой абстракцию взаимодействия между пользователем и сервером для реализации операции прерывания/продолжения во время процесса связи по протоколу без сохранения состояния.

процесс:

  1. Клиент: пользователь отправляет запрос на сервер в первый раз
  2. Сервер: получает данные и автоматически создает определенный идентификатор сеанса/сеанса для пользователя, чтобы идентифицировать пользователя и отслеживать процесс сеанса пользователя.
  3. Клиент: браузер получает соответствующую информацию о сеансе и передает идентификатор сеанса/сеанса в следующем запросе.
  4. Сервер: после извлечения сервер сравнивает его с локально сохраненным идентификатором сеанса/сеанса, чтобы найти сеанс конкретного пользователя, а затем получить статус сеанса.
  5. До сих пор общение между клиентом и сервером стало общением с отслеживанием состояния.

Возможности:

  1. Сессия сохраняется на сервере
  2. Через протокол автоматического шифрования сервера

Различия с файлами cookie:

  1. Безопасность Session лучше, чем у Cookie: поскольку Cookie существует на стороне клиента и может быть изменена, в то время как Session существует на сервере и не может быть подделан.
  2. Разные размеры: размер куки не превышает 4k
  3. Различные периоды действия: файлы cookie могут сохраняться в течение длительного времени, а сеансы обычно имеют более короткий срок действия.
  4. Типы значений доступа разные: Cookie поддерживает только строковые данные, а Session может хранить данные любого типа

Процесс аутентификации Session-Cookie

  1. Клиент: отправить информацию для входа (имя пользователя + пароль) на сервер
  2. Сервер: подтвердите имя пользователя + пароль
  3. Сервер: создайте идентификатор сеанса после прохождения проверки и сохраните его на сервере сеансов.
  4. Сервер: возвращает данные клиенту, а Set-Cookie:PHPSESSID=sid
  5. Клиент: нести Cookie и запрашивать ресурсы с сервера
  6. Сервер: проверьте сеанс через сервер сеансов.
  7. Сеансовый сервер: проверка прошла успешно
  8. Сервер: интерфейс для обработки данных
  9. Сервер: вернуть правильные данные клиенту

Преимущества сеансовых файлов cookie

  • Простые файлы cookie
  • Сессия существует на сервере, которым проще управлять, чем JWT.
  • Требуется только back-end операция, а front-end не имеет смысла

Недостатки сеансовых файлов cookie

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

3. Аутентификация токена

Некоторые недостатки Session-Cookie и нагрузка, которую обслуживание сеанса оказывает на сервер. Затем нам нужно было найти место для его хранения, и появился Токен.

Что такое токен?

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

Состав токена:

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

Процесс аутентификации токена

  1. Клиент отправляет данные для входа (имя пользователя + пароль) на сервер
  2. Сервер проверяет данные для входа, генерирует зашифрованный токен Token и возвращает его клиенту.
  3. После того, как клиент получит токен, сохраните его локально
  4. Когда клиент снова запрашивает данные API, он передает токен на сервер.
  5. После того, как сервер получает токен, он выполняет расшифровку и проверку подписи.
  6. Проверка прошла успешно, и сервер возвращает данные клиенту

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

  • Сервер не имеет состояния и имеет хорошую масштабируемость: механизму Token не нужно хранить информацию о сеансе на сервере, и он уже содержит информацию, связанную с пользователем.
  • Хорошая безопасность: избегайте CSRF
  • Поддержка междоменного доступа

Недостатки токенов

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

Поскольку токен действителен в течение короткого периода времени, существует Refresh Token (Обновить токен)

Что такое токен обновления?

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

Обновить процесс аутентификации токена

  1. Клиент: логин + пароль запросить верификацию входа
  2. Сервер: получите запрос, проверьте информацию для входа и верните токен доступа + токен обновления клиенту после успеха.
  3. Клиент: Сохраните полученный токен доступа + токен обновления локально; при повторном запросе данных API переносите токен доступа на сервер
  4. Сервер: убедитесь, что токен доступа действителен: верните обычные данные (недействителен: отклоните запрос)
  5. Срок действия токена клиентского доступа истек: повторно передайте токен обновления на сервер
  6. Срок действия токена доступа сервера истекает: после успешной проверки токена обновления клиенту возвращается новый токен доступа.
  7. Клиент: повторно используйте новый токен доступа, чтобы запросить API.

Разница между токеном и сеансовым файлом cookie

Токен больше похож на улучшенную и обновленную версию Session-Cookie.

  • Различные места хранения: Сессия существует на сервере; Токен не имеет состояния и обычно хранится во внешнем интерфейсе.
  • Другая безопасность: безопасность токена лучше, чем сеанса, потому что каждый запрос имеет подпись и может предотвратить мониторинг
  • Различная поддержка: Session-Cookie должен быть реализован механизмом cookie браузера, и он не будет работать при обнаружении собственного приложения NativaApp (или если хранилище cookie браузера отключено); Механизм проверки токенов обогащает типы клиентов

Аутентификация JWT (веб-токен JSON)

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

Что такое ЮВТ?

JWT — это схема, предложенная Auth0 для реализации проверки авторизации путем криптографической подписи SON.

После успешного входа в систему соответствующая информация будет объединена в объект JSON, каким-то образом зашифрована и возвращена клиенту. Клиент принесет этот Токен при следующем запросе, а сервер проверит его легитимность.

Состав JWT

  • Заголовок: type (тип токена, тип JWT) + alg (алгоритм хеширования, ‘HS256’)
  • Загрузка полезной нагрузки: содержит несколько объявлений для хранения данных, которые действительно необходимо передать.
  • Подпись подписи: Подпишите две вышеуказанные части без подделки.

Разделите три части точкой (.) посередине следующим образом:

 eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Как использовать JWT

Клиент получает возвращенный сервером JWT, который может быть сохранен в Cookie или localStorage.

Впоследствии, при запросе API, вам нужно принести этот JWT. Его можно поместить в файл cookie и отправить автоматически, но это не может быть междоменным, поэтому он обычно помещается в поле «Авторизация» информации заголовка HTTP-запроса.

Процесс аутентификации JWT

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

  1. Клиент: Отправить данные для входа (имя пользователя + пароль)
  2. Сервер: проверьте информацию для входа, создайте JWT с ключом; вернуть JWT клиенту
  3. Клиент: сохраните его локально после получения JWT; затем вызовите API для переноса JWT в заголовок запроса.
  4. Клиент: проверьте, действителен ли JWT, получите информацию о пользователе от JWT, обработайте связанные данные и верните данные клиенту.

Преимущества JWT

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

Недостатки JWT

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

5. Единый вход

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

SSO в том же домене (то же основное доменное имя)

При наличии двух подсистем Tieba tieba.baidu.comи pan.baidu.com этапы реализации SSO для них следующие:

  1. Клиент: когда пользователь получает доступ к определенной подсистеме, если он не вошел в систему, он перейдет на страницу входа, предоставленную центром аутентификации SSO, для входа.
  2. Сервер: после аутентификации входа сервер сохраняет информацию о вошедшем в систему пользователе в сеансе и добавляет ее в соответствующее поле заголовка Set-Cookie. Установите домен файла cookie: .baidu.com
  3. Клиент: при повторной отправке запроса отправьте его на сервер с файлом cookie под основным доменным именем Домен, и в это время сервер может проверить статус входа в систему через файл cookie.

6. ОАут 2.0

Когда мы фактически просматриваем веб-сайт, в дополнение к вводу имени пользователя и пароля существуют сторонние методы входа в систему, такие как WeChat и QQ. На этот раз мы поговорим об OAuth.

Существует две версии протокола OAuth: 1.0 и 2.0. Весь процесс проверки авторизации версии 2.0 проще и безопаснее, и в настоящее время это самый важный метод аутентификации и авторизации пользователей.

Что такое OAuth 2.0?

OAuth — это открытый стандарт, который позволяет пользователям разрешать сторонним веб-сайтам (CSDN и т. д.) получать доступ к информации, которую они предоставляют, хранящейся на другом сервере, без предоставления имени пользователя и пароля стороннему веб-сайту.

Распространенные поставщики, предоставляющие услуги аутентификации OAuth: Alipay, QQ, WeChat, Weibo.

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

Различия между токенами и паролями:

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

7. Федеративный вход и надежный вход

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

С точки зрения непрофессионала: для двух веб-сайтов A и B используйте пароль учетной записи веб-сайта B при входе на веб-сайт A, что является совместным входом в систему, или используйте пароль учетной записи веб-сайта A при входе на веб-сайт B, что также является совместным входом. .

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

С точки зрения непрофессионала: когда веб-сайт А имеет статус входа в систему, вы можете перейти непосредственно на веб-сайт Б без входа в систему, что означает, что вы доверяете входу в систему.

8. Уникальный логин

Уникальный логин относится к запрету одновременного входа нескольких людей в одну и ту же учетную запись. Поведение последнего при входе в систему приведет к отключению первого.

Пользователь работает на клиенте A:

  • Войдите в интерфейс входа в учетную запись
  • Бэкенд генерирует соответствующий токен и возвращает его клиенту А, а также сохраняет статус входа на сервер.
  • Клиент A сохраняет токен, и каждый запрос содержит соответствующий токен в заголовке.

Пользователь работает на клиенте B:

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

9. Отсканируйте код для входа

Двумерный код также называют двумерным штрих-кодом. Распространенным двумерным кодом является QR-код. Полное название QR — Quick Response. В последние годы это очень популярный метод кодирования на мобильных устройствах. Он может хранить больше. Информация также может представлять больше типов данных.

Из вышеизложенного нетрудно обнаружить, что для входа в систему с помощью сканирующего кода требуется взаимодействие трех терминалов (ПК-терминал, мобильный терминал, серверный терминал) для достижения эффекта успешного входа в систему;

Подробное объяснение шагов сканирования кода для входа в систему (для сканирования, для подтверждения, для подтверждения)

Для сканирования:

  1. Сторона ПК: откройте веб-сайт (например, taobao.com) или приложение (например, WeChat), чтобы отсканировать код для входа в систему; он будет нести информацию об устройстве на стороне ПК и отправлять запрос на сервер для получения QR-кода;
  2. Сервер: после получения запроса сервер случайным образом генерирует UUID в качестве идентификатора QR-кода, связывает UUID с информацией об устройстве на ПК, сохраняет его на сервере Redis, а затем возвращает на ПК; в то же время установите время истечения срока действия, после истечения которого пользователю необходимо обновить QR-код, чтобы получить его снова.
  3. ПК-терминал: после получения идентификатора QR-кода отобразите идентификатор QR-кода в виде QR-кода и подождите, пока мобильный терминал отсканирует код. И в это время ПК начинает опрашивать статус QR-кода до тех пор, пока вход в систему не будет успешным. Если мобильный терминал не сканирует, QR-код автоматически становится недействительным через определенный период времени.

Проверено и ожидает подтверждения:

  1. Мобильный терминал: откройте мобильный терминал, соответствующий зарегистрированному приложению (WeChat или Taobao и т. д.), и начните сканирование, чтобы идентифицировать QR-код, отображаемый на терминале ПК; после того, как мобильный терминал отсканирует QR-код, он автоматически получит идентификатор QR-кода и мобильный терминал. Учетные данные для входа в систему (токен) и идентификатор QR-кода отправляются на сервер в качестве параметров. В это время мобильный телефон должен быть зарегистрирован (предпосылка использования входа в систему сканирования заключается в том, что мобильное приложение входит в систему, чтобы можно было поделиться статусом входа).
  2. Сервер: после получения запроса с мобильного телефона он свяжет токен с идентификатором QR-кода. Зачем вам это нужно? Потому что, когда мы используем WeChat, когда мобильный терминал выходит из системы, ПК-терминал также должен выходить из системы и входить в нее, и эта ассоциация играет эту роль. Затем будет сгенерирован временный Токен, который будет возвращен на мобильный терминал, а одноразовый Токен будет использоваться в качестве учетных данных для подтверждения.

Подтвержденный этап:

  1. Мобильный терминал: после получения подтверждающего сообщения нажмите кнопку «Подтвердить», и мобильный терминал перенесет временный токен, полученный на предыдущем шаге, и отправит его на сервер для проверки.
  2. Сервер: после завершения проверки сервера статус QR-кода будет обновлен, и для ПК будет сгенерирован формальный токен, а последующий ПК будет удерживать этот токен для доступа к серверу.
  3. ПК: статус опроса QR-кода зарегистрирован, и сгенерированный токен будет получен, вход в систему завершен, и последующий доступ будет завершен на основе токена.

10. Вход в один клик

Возможность входа в систему одним щелчком мыши зависит от того, открыл ли оператор соответствующие услуги; поскольку оператор открыл сопутствующие услуги, теперь мы можем получить доступ к SDK, предоставленному оператором, и оплатить сопутствующие услуги.

Подробные шаги для входа в один клик:

  1. Инициализация SDK: вызовите метод SDK и передайте AppKey и AppSecret, настроенные платформой.
  2. Вызов страницы авторизации: вызовите SDK, чтобы вызвать интерфейс авторизации. SDK сначала инициирует запрос оператору на получение маски номера мобильного телефона. После успешного выполнения запроса он перейдет на страницу авторизации. На странице авторизации отобразится маска номера мобильного телефона и операторское соглашение для подтверждения пользователя.
  3. Согласен на авторизацию и вход: пользователь соглашается с соответствующим соглашением, нажимает кнопку входа на странице авторизации, и SDK запросит токен для получения этого номера и вернет токен клиенту после успешного запроса.
  4. Получите номер: отправьте полученный токен на свой собственный сервер, и сервер будет нести токен для вызова интерфейса входа в систему с одним ключом оператора и вернуть номер мобильного телефона, если вызов будет успешным. Сервер использует номер мобильного телефона для входа или регистрации и возвращает результат операции клиенту для завершения входа в систему в один клик.