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

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

---

1. Куки + вход в сессию

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

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

В системе B/S функция входа в систему обычно основана наCookieбыть реализованным. Когда пользователь входит в систему успешно, статус входа обычно записывается вSessionсередина. Чтобы реализовать проверку данных для входа клиента на стороне сервера, необходимо сохранить некоторую информацию на стороне клиента (SessionId) и требовать от клиента выполнять их при каждом последующем запросе. В таком случае используйтеCookieнесомненно, самый удобный, поэтому мы обычно используемSessionизIdСохранитьCookie, когда сервер получает запрос, он проходит проверкуCookieчтобы определить, вошел ли пользователь в систему или нет.

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

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

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

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

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

После завершения первого входа в систему последующие посещения могут использоваться напрямую.CookieАутентифицировано:

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

резюме

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

1. Поскольку стороне сервера необходимо подключаться к большому количеству клиентов, ей также необходимо хранить большое количествоSessionId, что вызовет чрезмерную нагрузку на сервер.
2. Если серверная часть представляет собой кластер, для синхронизации состояния входа в систему необходимоSessionIdСинхронизация с каждой машиной фактически увеличивает затраты на обслуживание на стороне сервера.
3. из-заSessionIdвставитьCookie, так что это неизбежноCSRFатака.

---

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

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

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

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

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

1. Доступ пользователяa.com/pageA, введите пароль учетной записи и нажмите Войти.
2. Сторона сервера проверяет правильность пароля учетной записи, создаетToken.
3. Сервер будетTokenвозвращена клиенту черезСвобода сохранения клиента.

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

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

Метод генерации токена

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

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

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

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

• headerчасть определяетJWTиспользуемый алгоритм подписи;
• playloadчасти шоуJWTцель;
• signatureчастьJWTподпись, в основном, чтобы позволитьJWTВ него нельзя вмешиваться по своему желанию.

оJWT, вот краткое описание, можно перейти к конкретным деталямофициальный сайт ДВТ.

резюме

Согласно приведенному выше случаю, мы можем проанализироватьTokenПреимущества и недостатки:

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

имеютTokenПосле этого метод входа в систему стал очень эффективным.

---

3. Единый вход SSO

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

Процесс внедрения механизма SSO

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

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

После завершения входа в центр аутентификации продолжайте посещатьa.comДругие страницы под:

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

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

В настоящее время, поскольку центр аутентификации ранее вошел в системуCookie, поэтому вам не нужно снова вводить пароль учетной записи, вернитесь к шагу 4 и отправьтеticketДатьb.comВот и все.

Реализация механизма SSO

Существует три основных способа реализации единого входа:

1. Файлы cookie родительского домена
2. Удостоверяющий центр
3. Кросс-доменное LocalStorage

При нормальных обстоятельствах статус входа пользователя записывается вSessionЧтобы достичь общего состояния входа в систему, вы должны сначала поделитьсяSession, но так как разные системы приложений имеют разные доменные имена, хотяSessionобщий, но из-заSessionIdчасто сохраняется в браузереCookie, поэтому существует ограничение области действия, и его нельзя передавать между доменными именами, то есть, когда пользователь находится вa.comПосле входа в системуSession IdДоступ только через браузерa.comбудет автоматически переноситься в заголовок запроса, и когда браузер обращается кb.comчас,Session Idне возьмут. Ключ к реализации единой регистрации заключается в том, как сделатьSession Id(или токен), общий для нескольких доменов.

1. Печенье родительского домена

CookieОбъем определяетсяdomainсвойства иpathсвойства определяются совместно.domainДопустимыми значениями атрибута являются доменное имя/IP-адрес текущего домена или его родительского домена в Tomcat,domainСвойство по умолчанию соответствует доменному имени/IP-адресу текущего домена.pathДопустимые значения свойства: "/«Путь начинается в Томкэте,pathПо умолчанию свойство соответствует текущему контекстному пути веб-приложения.

еслиCookieизdomainсвойство установлено в родительский домен текущего домена, тогда он считается родительским доменомCookie.CookieЕсть особенность, что родительский доменCookieРазделяется субдоменом, то есть субдомен автоматически наследуетCookie.

использоватьCookieЭта особенностьSession Id(илиToken) можно сохранить в родительском домене. нам просто нужноCookieизdomainсвойство установлено в доменное имя родительского домена (имя основного домена), в то время какCookieизpathДля свойства задан корневой путь, чтобы все приложения поддоменов могли получить к нему доступ.Cookie. Однако для этого требуется, чтобы доменное имя прикладной системы было установлено под общим основным доменным именем, таким как tieba.baidu.com и map.baidu.com, оба из которых установлены под основным доменным именем baidu. com, то они могут использовать этот способ достижения единого входа.

Резюме: эта реализация относительно проста, но не поддерживает перекрестные первичные доменные имена.

2. Центр сертификации

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

Пользователь входит в центр аутентификации унифицированным способом.После успешного входа центр аутентификации записывает статус входа пользователя и записывает статус входа пользователя.TokenзаписыватьCookie. （注意这个CookieЭто сертификационный центр, применение системы недоступна)

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

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

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

3. Междоменное хранилище LocalStorage

Ключ к единому входу в том, как сделатьSession Id(илиToken) совместно используется несколькими доменами. ноCookieПерекрестное основное доменное имя не поддерживается, и браузер не поддерживаетCookieОграничения кросс-домена получают более строгих.

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

В таком сценарии единый вход может быть полностью реализован на внешнем интерфейсе. внешний интерфейсSession Id(илиToken), в дополнение к записи его в свой собственныйLocalStorageВ дополнение к , он также может быть записан в несколько других доменов специальными средствами.LocalStorageсередина.

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

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

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

Принцип на самом деле не сложный, это можно проверить в сертификационном центре в каждом товареticket(token)На самом деле, вы можете выйти из своего собственногоapiнаправляется в удостоверяющий центр.

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

1. пустойc.comвойти в системуCookie.
2. Запрос центра сертификацииsso.comвыход вapi.
3. Удостоверяющий центр прошел и выдалticket(token)всех продуктов и вызвать соответствующий выходapi, завершите выход.

---

В-четвертых, сторонний вход OAuth

Сторонние методы входа 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, с временным билетомcode.
7. ПолучатьcodeПозже,a.comвозьметcode,appid,appsecret, подать заявку на сервер WeChattoken, после успешной проверки WeChat отправитtoken.
8. имеютtokenПозже,a.comможно положиться наtokenПолучите соответствующий аватар пользователя WeChat, псевдоним пользователя и другую информацию.
9. a.comПредложите пользователю успешно войти в систему и запишите статус входа вCookie, в качестве учетных данных для последующего доступа.

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

---

Суммировать

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

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

---

Справочная статья:блог cn на.com/eternal/… Tickets.WeChat.QQ.com/Yes/Green Grass 6TP X…