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

• Файл cookie + вход в сеанс
• Вход по токену
• Единый вход SSO
• Сторонний вход OAuth

Файл cookie + вход в сеанс

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

Чтобы решить проблему безгражданства HTTP,Lou MontulliФайлы cookie были представлены в 1994 году.

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

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

Когда клиент запрашивает сервер, сервер открывает пространство памяти для этого запроса, которое является объектом Session.

С помощью файлов cookie и сеанса мы можем выполнить аутентификацию при входе в систему.

Процесс реализации Cookie + Session

Метод входа в систему с помощью cookie + сеанса является наиболее классическим методом входа в систему и до сих пор используется большим количеством предприятий.

Когда пользователь входит в систему в первый раз:

1. Доступ пользователяa.com/pageA, и введите свой пароль для входа.
2. После проверки сервером правильности пароля он создает SessionId и сохраняет его.
3. Сервер отвечает на этот HTTP-запрос и записывает SessionId в файл cookie через заголовок Set-Cookie.

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

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

1. Доступ пользователяa.com/pageBКогда страница отображается, файл cookie, записанный во время первого входа в систему, будет автоматически сохранен.
2. Сервер сравнивает, соответствует ли SessionId в файле cookie идентификатору SessionId, хранящемуся на сервере.
3. Если они совпадают, аутентификация проходит успешно.

Проблемы с куки + сессия

Хотя мы используем Cookie + Session для завершения проверки входа, все еще есть некоторые проблемы:

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

Вход по токену

Чтобы решить многие проблемы, связанные с механизмом Session + Cookie, мы можем использовать метод входа в систему Token.

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

Процесс реализации механизма токенов

Когда пользователь входит в систему в первый раз:

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

При последующих посещениях страницы:

1. Доступ пользователяa.com/pageB, принесите Токен, полученный при первом входе в систему.
2. Токен проверки на стороне сервера, если он действителен, аутентификация прошла успешно.

Особенности механизма токенов

В соответствии с приведенным выше случаем мы можем проанализировать преимущества и недостатки токена:

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

Как генерируются токены

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

Как упоминалось выше, после использования токена сервер не хранит токен, поэтому как определить, является ли токен, отправленный клиентом, законным и действительным?

Ответ на самом деле в строке Token.На самом деле Token это не строка беспорядочных строк, а строка, которая склеена и объединена различными алгоритмами.Давайте разберем ее подробно.

Алгоритм JWT в основном делится на три части: заголовок (информация заголовка), полезная нагрузка (тело сообщения) и подпись (подпись).

Раздел заголовка определяет алгоритм подписи для этого JWT:

header = '{"alg":"HS256","typ":"JWT"}'   // `HS256` 表示使用了 HMAC-SHA256 来生成签名。

Раздел playload указывает на цель JWT:

payload = '{"loggedInAs":"admin","iat":1422779638}'     //iat 表示令牌生成的时间

Часть подписи - это подпись JWT. Основная цель состоит в том, чтобы предотвратить подделку JWT по желанию. Метод подписи делится на два этапа:

1. войтиbase64urlзакодированный раздел заголовка,.,base64urlЗакодированная часть полезной нагрузки, выходной токен без знака.
2. Введите закрытый ключ на стороне сервера, unsignedToken, и выведите подпись подписи.

const base64Header = encodeBase64(header)
const base64Payload = encodeBase64(payload)
const unsignedToken = `${base64Header}.${base64Payload}`
const key = '服务器私钥'

signature = HMAC(key, unsignedToken)

Окончательный расчет токена выглядит следующим образом:

const base64Header = encodeBase64(header)
const base64Payload = encodeBase64(payload)
const base64Signature = encodeBase64(signature)

token = `${base64Header}.${base64Payload}.${base64Signature}`

Когда сервер оценивает токен:

const [base64Header, base64Payload, base64Signature] = token.split('.')

const signature1 = decodeBase64(base64Signature)
const unsignedToken = `${base64Header}.${base64Payload}`
const signature2 = HMAC('服务器私钥', unsignedToken)

if(signature1 === signature2) {
  return '签名验证成功，token 没有被篡改'
}

const payload =  decodeBase64(base64Payload)
if(new Date() - payload.iat < 'token 有效期'){
  return 'token 有效'
}

С помощью Token метод входа в систему стал очень эффективным.Далее мы представим два других метода входа.

Единый вход SSO

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

Процесс реализации механизма SSO

Когда пользователи получают доступ в первый раз, им необходимо войти в центр аутентификации:

1. Пользователь заходит на сайтa.compageA под страницей.
2. Поскольку логина нет, он будет перенаправлен в центр аутентификации с адресом обратного вызова.www.sso.com?return_uri=a.com/pageA, так что вы можете сразу войти на соответствующую страницу после входа в систему.
3. Пользователь вводит пароль учетной записи в центре аутентификации и отправляет логин.
4. Центр аутентификации проверяет правильность пароля учетной записи, а затем перенаправляетa.com?ticket=123Принесите билет с кодом авторизации и отправьте в удостоверяющий центр.sso.comСтатус входа в файл cookie записывается.
5. существуетa.comВ сервере возьмите тикет и подтвердите в удостоверяющем центре, что тикет с кодом авторизации настоящий и действующий.
6. После успешной проверки сервер записывает данные для входа в куки (в это время у клиента 2 куки хранятся отдельноa.comа такжеsso.comстатус входа).

---

После того, как центр сертификации вошел в систему, продолжайте доступa.comДругие страницы под:

В это время из-заa.comЗаписывается информация о файлах cookie, поэтому прямая аутентификация на стороне сервера проходит успешно.

---

Если вход в центр аутентификации завершен, доступb.comстраница ниже:

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

Выход из системы единого входа

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

Принцип на самом деле не сложный, можно вернуться к шагу 5. Когда каждый продукт проверяет тикет в удостоверяющий центр, он фактически может отправить в удостоверяющий центр свой собственный logout api.

когда продуктc.comПри выходе из системы:

1. пустойc.comФайлы cookie для входа в .
2. Запрос центра сертификацииsso.comВыход из API в .
3. Центр сертификации просматривает все продукты, для которых были выпущены тикеты, и вызывает соответствующий выходной API для завершения выхода.

Сторонний вход OAuth

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

На самом деле, есть. Многие крупные производители обеспечит свои собственные сторонние услуги входа в систему. Давайте проанализируем их вместе.

Процесс реализации механизма OAuth

Вот пример процесса доступа к открытой платформе WeChat:

1. первый,a.comОператору компании необходимо зарегистрировать учетную запись на открытой платформе WeChat и подать заявку в WeChat, чтобы использовать функцию входа в WeChat.
2. После успешного выполнения приложения будут получены appid и appsecret приложения.
3. пользователь вa.comВыберите вход с помощью WeChat.
4. В это время он перейдет к логину авторизации OAuth WeChat и принесет его сa.comадрес обратного звонка.
5. Пользователь вводит учетную запись WeChat и пароль, и после успешного входа в систему ему необходимо выбрать конкретную область авторизации, такую ​​как аватар авторизованного пользователя, псевдоним и т. д.
6. После авторизации WeChat подтянется поa.com?code=123, затем принесите временный код билета.
7. Получив код,a.comОн будет содержать код, appid и appsecret для подачи заявки на токен на сервер WeChat.После успешной проверки WeChat выдаст токен.
8. Получив токен,a.comВы можете использовать токен для получения соответствующего аватара пользователя WeChat, псевдонима пользователя и другой информации.
9. a.comСообщите пользователю об успешном входе в систему и запишите статус входа в файл cookie в качестве учетных данных для последующего доступа.

Суммировать

В этой статье представлены 4 распространенных метода входа в систему. Принципы должны быть понятны всем. Подытожим сценарии использования этих 4 схем:

• Cookie + Session имеет давнюю историю и подходит для простой серверной архитектуры, а разработчикам приходится самим решать вопросы безопасности.
• Схема Token оказывает небольшое давление на серверную часть и подходит для крупномасштабной распределенной серверной архитектуры, однако неудобно отзывать разрешения распределенных токенов.
• Единый вход SSO, подходящий для средних и крупных предприятий, которые хотят унифицировать метод входа во все внутренние продукты.
• Сторонний вход OAuth, простой в использовании, удобный для пользователей и разработчиков, но существует множество сторонних платформ, вам необходимо выбрать подходящую стороннюю платформу для входа.