Общие схемы аутентификации при входе

HTTP
Общие схемы аутентификации при входе

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

задний план

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

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

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

Введение

HTTP обеспечивает общую основу для контроля авторизации и аутентификации. Наиболее часто используемая схема HTTP-аутентификации — базовая HTTP-аутентификация.

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

Процесс шифрования и дешифрования

// Authorization 加密过程
let email = "postmail@test.com"
let password = "12345678"
let auth = `${email}:${password}`
const buf = Buffer.from(auth, 'ascii');
console.info(buf.toString('base64')); // cG9zdG1haWxAdGVzdC5jb206MTIzNDU2Nzg=

// Authorization 解密过程
const buf = Buffer.from(authorization.split(' ')[1] || ''),  'base64');
const user = buf.toString('ascii').split(':');

Другая HTTP-аутентификация

Существует несколько схем аутентификации, используемых в Generic HTTP Authentication Framework. Различные схемы аутентификации будут иметь разную степень безопасности.

IANA поддерживаетАссортимент схем проверки, в дополнение к другим типам схем аутентификации, предоставляемым службами виртуального хостинга, такими как Amazon AWS, распространенные схемы аутентификации включают:

  • Базовый (ПросмотрRFC 7617, учетные данные в кодировке Base64. Подробнее см. ниже.),
  • Предъявитель (ПросмотрRFC 6750, токены-носители защищают ресурсы через OAuth 2.0),
  • Дайджест (ПросмотретьRFC 7616, в Firefox поддерживаются только хеши md5, см.bug 472823для поддержки шифрования SHA),
  • ХОБА (ПросмотретьRFC 7486(черновик), HTTP-аутентификация с привязкой к происхождению, на основе цифровой подписи),
  • Взаимный (Просмотрdraft-ietf-httpauth-mutual),
  • AWS4-HMAC-SHA256 (ПросмотрAWS docs)

2. Файл cookie + сеанс

процесс регистрации

Подумайте: зачем добавлять в пароль немного «соли»?

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

Хранилище сеансов

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

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

Session Refresh

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

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

оптимизация:

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

Вход с одного устройства

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

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

3. ЮВТ

Введение

JSON Web Token (JWT) — это открытый стандарт (RFC 7519), определяющий компактный автономный способ безопасной передачи информации между сторонами в виде объектов JSON. Эту информацию можно проверить и доверять ей, поскольку она имеет цифровую подпись.

Состав JWT

JWT состоит из трех частей, а именно заголовка (header), полезной нагрузки (load) и подписи (visa), которые соединены десятичными точками.

Например, используйте файл cookie с именем jwt-token для хранения примера JWT:

jwt-token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYW1lIjoibHVzaGlqaWUiLCJpYXQiOjE1MzI1OTUyNTUsImV4cCI6MTUzMjU5NTI3MH0.WZ9_poToN9llFFUfkswcpTljRDjF4JfZcmqYS0JcKO8;

использовать.Значение разделения можно разделить на три части, которые расположены по порядку:

  • header:

    • Значение: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
    • Декодирование Base64:{"alg": "HS256", "type": "JWT"}

  • payload:

    • Значение: eyJuYW1lIjoibHVzaGlqaWUiLCJpYXQiOjE1MzI1OTUyNTUsImV4cCI6MTUzMjU5NTI3MH0
    • Декодирование Base64:
      {
  "name": "lushijie", 
  "iat": 1532595255, // 发布时间
  "exp": 1532595270 // 过期时间
}

  • signature:

    • Значение: WZ9_poToN9llFFUfkswcpTljRDjF4JfZcmqYS0JcKO8.
    • расшифровка:
      const headerEncode = base64Encode(header);
const payloadEncode = base64Encode(payload);
let signature = HMACSHA256(headerEncode + '.' + payloadEncode, '密钥');

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

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

Кроме того, относительно просто проверить, является ли JWT действительным.Сервер вычисляет подпись в соответствии с методом расчета, описанным выше, и сравнивает ее с частью подписи проверяемого JWT.Если часть подписи равна, это действующий JWT.

Token Refresh

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

решение:

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

4. ОАут

Введение

Иногда мы заходим на определенный веб-сайт, но не хотим регистрировать учетную запись для веб-сайта.В настоящее время мы можем войти с помощью сторонней учетной записи, такой как github, Weibo, WeChat, QQ и т. д. .

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

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

OAuth — это дополнение к OpenID, но совершенно другой сервис.

- из Википедии

Процесс авторизации

Глоссарий:

  • Стороннее приложение: Стороннее приложение также называется «клиент» (клиент). Например, откройте Zhihu, используйте сторонний логин и выберите Github для входа. В настоящее время Zhihu является клиентом.
  • Владелец ресурса. Владелец ресурса, также известный как «пользователь» в этой статье, — это вошедший в систему пользователь.
  • Сервер авторизации: сервер аутентификации, то есть сервер, который Github использует исключительно для обработки аутентификации.
  • Сервер ресурсов: сервер ресурсов, то есть сервер, на котором Github хранит ресурсы, созданные пользователями. Он и сервер аутентификации могут быть одним сервером или другим сервером.

  • A. Веб-сайт A позволяет пользователям перейти на GitHub и запросить код авторизации, GitHub требует, чтобы пользователи вошли в систему, а затем спрашивает: «Веб-сайт Zhuhu требует разрешения xx, вы согласны?»;
  • B. Если пользователь соглашается, GitHub перенаправит обратно на веб-сайт A и отправит код авторизации;
  • C. Веб-сайт A использует код авторизации для запроса токена от GitHub;
  • D. GitHub возвращает токен;
  • E. Веб-сайт A использует токен для запроса пользовательских данных у GitHub;

Другие режимы авторизации

Режим кода авторизации (код авторизации) — это режим авторизации с наиболее полными функциями и самым строгим процессом. Кроме режима кода авторизации, о котором мы упоминали выше, существуют и другие режимы авторизации:

  1. Упрощенный режим (тип неявного предоставления)

Некоторые веб-приложения представляют собой чистые интерфейсные приложения без серверной части. В настоящее время вышеуказанный метод использовать нельзя, и токен должен храниться во внешнем интерфейсе. В RFC 6749 указан второй способ, позволяющий выдавать токены непосредственно во внешний интерфейс. Таким образом, нет промежуточного шага кода авторизации 2. Режим пароля (предоставление учетных данных владельца ресурса)
Если у вас высокий уровень доверия к приложению, RFC 6749 также позволяет пользователям напрямую сообщать приложению свое имя пользователя и пароль. Приложение использует ваш пароль для запроса токена 3. Режим клиента (предоставление учетных данных клиента)
Применимо к приложениям командной строки без внешнего интерфейса, т.е. запрашивающим токены из командной строки.

Подробнее об этих режимах см.Четыре способа OAuth2.0

войти

Единый вход (Single Sign On, SSO), а именно: единый вход (single sign-on) вход в систему. Например: QQ, я один раз захожу в пространство QQ, я могу получить доступ к другим службам продуктов QQ: почтовый ящик QQ, новости Tencent и т. д., и все это может гарантировать, что ваша учетная запись останется в системе.

Дальнейшее чтение:

V. Резюме и сравнение

Нет лучшего, есть самое подходящее! ! !

  • Аутентификация HTTP-аутентификации:
    • Суммировать:
      Существует несколько схем аутентификации, используемых в Generic HTTP Authentication Framework. Различные схемы аутентификации будут иметь разную степень безопасности. Аутентификация HTTP Authentication — наиболее часто используемая схема аутентификации HTTP.Чтобы снизить риск утечки, обычно требуется протокол HTTPS.
    • Применимая сцена:
      Обычно он используется в системах с низкими требованиями к внутренней безопасности, таких как веб-интерфейсы управления маршрутизатором.
    • проблема:
      1. Запрос содержит аутентификационную информацию, которую легко перехватить.
      2. Не могу выйти
  • Файл cookie + сеанс:
    • Суммировать:
      • Сервер сохраняет сеанс, а клиент сохраняет файл cookie, где файл cookie хранится как идентификатор сеанса.
      • Он может гибко отзывать разрешения, а после обновления информации соответствующий контент в сеансе можно легко синхронизировать.
      • Распределенные сеансы обычно используют хранилище Redis (или другое KV).
    • используемые сцены:
      Подходит для независимой аутентификации традиционных систем
  • ЮВТ:
    • Суммировать:
      • Серверу больше не нужно хранить сеанс, а аутентификацию сервера и службу аутентификации можно легко расширить.
      • JWT не полагается на файлы cookie и также может передаваться с помощью заголовков.
      • Чтобы уменьшить кражу, используйте протокол HTTPS для передачи
    • Применимая сцена:
      • Подходит для простой аутентификации RESTful API
      • Подходит для разовой проверки, например, ссылка для активации регистрации
    • проблема:
      1. Токен нельзя сбросить во время использования, и токен всегда действителен в течение срока действия.
      2. Когда полезная информация обновляется, выданный токен не может быть синхронизирован
  • ОАут:
    • Суммировать:
      • OAuth — это открытый стандарт, который позволяет пользователям разрешать сторонним приложениям получать доступ к информации, которую они хранят у другого поставщика услуг, без необходимости предоставлять имена пользователей и пароли сторонним мобильным приложениям или делиться всеми своими данными.
      • Документация GitHub OAuthIdentifying and authorizing users for GitHub Apps
    • Применимая сцена:
      OAuth делится на следующие четыре режима.
      1. Упрощенный режим, небезопасный, подходит для приложений с чистыми статическими страницами.
      2. Режим кода авторизации, режим авторизации с наиболее полными функциями и самым строгим процессом, обычно используемый на открытой платформе общедоступной сети.
      3. Режим пароля, обычно используемый во внутренних системах, вызывающий абонент является единицей пользователя.
      4. Клиентский режим, как правило, для вызовов API между внутренними системами. Вызывается между двумя платформами в единицах платформы.
Категории