Поговорите о внешнем и внутреннем разделении и вариантах аутентификации.

задняя часть

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

В последние несколько лет «разделение front-end и back-end» в сфере веб-разработки было относительно популярным, и сейчас оно постепенно стало стандартом де-факто. Но что такое разделение интерфейса и сервера? А зачем разделение на перед и зад?

Что такое разделение фронтенда и бэкенда? Зачем разделять перед и зад?

Разделение передней и задней части является скорее архитектурной концепцией. В традиционной веб-архитектуре, такой как классический MVC, есть уровень данных, уровень логики и уровень представления. Этот слой представления — это то, что мы называем внешним интерфейсом, который сопоставляется со слоем кода, представляющим собой файлы кода, такие как html, js и css. Уровень данных и уровень логики — это скорее внутренняя часть, как и наша.java,.go,.pyи другие документы. Эти файлы будут в проекте и не будут разрабатываться, тестироваться и развертываться отдельно.

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

Разделение передней и задней части имеет ряд преимуществ:

1/ Разделите фронтенд- и бэкэнд-работниковПусть front-end и back-end передаются людям, которые в этом лучше разбираются, а виды работ дорабатываются, которые могут быть более специализированными. Внешний персонал заботится о пользовательском опыте, дизайне пользовательского интерфейса и интерактивном рендеринге; внутренний персонал уделяет больше внимания бизнес-логике, обеспечению производительности и безопасности. С точки зрения прогресса проекта, передняя и задняя части могут разрабатываться параллельно, не влияя друг на друга, что ускоряет общий ход проекта.

2/Развязанный внешний и внутренний кодБэкэнд должен только предоставлять услуги API и больше не взаимодействовать со статическими файлами. Серверная часть может использовать более сложную распределенную и микросервисную архитектуру, чтобы обеспечить лучшую производительность и гарантии стабильности. В то же время, в дополнение к стороне ПК, мобильная сторона также может использовать тот же набор внутренних сервисов.

Глядя здесь, становится понятно, что разделение интерфейсов и серверов широко используется.

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

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

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

  • Session-Cookie
  • Проверка токена
  • OAuth (открытая авторизация)

Метод Session-Cookie

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

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

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

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

Метод токена

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

  • 1/ Пользователь входит в систему с именем пользователя и паролем и отправляет имя пользователя и пароль на сервер.
  • 2/ Сервер проверяет имя пользователя и пароль и, если они верны, выдает токен и возвращает его пользователю.
  • 3/После того, как пользователь получает токен, он сохраняется.Веб-сервис, как правило, localStrage или cookie.
  • 4/ Когда пользователи запрашивают другие страницы ресурсов, они будут нести токены, которые обычно помещаются в заголовки или параметры и отправляются на сервер.
  • 5/После того, как сервер его получает, он проверяет токен и оценивает правильность пользователя.

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

Метод OAuth

OAuth (открытая авторизация) — это открытый стандарт, который позволяет пользователям разрешать сторонним веб-сайтам доступ к их пользовательской информации, хранящейся на сервере. Наши распространенные сторонние логины, такие как QQ и WeChat, являются методами аутентификации Auth. Протокол OAuth имеет две версии: 1.0 и 2.0. По сравнению с версией 1.0 весь процесс проверки авторизации версии 2.0 проще и безопаснее, а также является наиболее важным методом аутентификации и авторизации пользователя в настоящее время.

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

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

Противоположное мышление

Помимо менее часто используемого OAuth, здесь приведено сравнение первых двух часто используемых методов аутентификации JWT Auth и Session-Cookie Auth, которые являются лучшей практикой для разделения аутентификации от внешнего и внутреннего интерфейса. Проанализируйте сравнение со следующих направлений.

Масштабируемость

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

Метод Session-CookieНа основе файлов cookie, то есть это должен быть фрейм, инкапсулированный браузером или браузером, поддерживающим файлы cookie, и его нельзя использовать на чисто мобильных терминалах. JWT отличается,Не полагается на куки, если его можно хранить локально.

безопасность

Двумя распространенными проблемами безопасности в веб-разработке являются XSS (межсайтовые сценарии) и CSRF (подделка межсайтовых запросов). Первый использует сценарий внедрения на веб-сайт аутентификации пользователя для выполнения вредоносного кода сценария. Последний использует механизм доступа браузера к серверной части для автоматического переноса файлов cookie для подделки запросов между сайтами. XSS можно решить, если мы фильтруем и избегаем конца инъекции, а CSRF находится в центре нашего внимания.

В методе аутентификации Session-Cookie, поскольку SessionID хранится в файле cookie, легко вызвать атаки CSRF. В большинстве WEB-фреймворков есть интегрированные решения, такие как csrftoken от Django, xsrfToken от Beego и т. д. При использовании решения Session-Cookie рекомендуется включить функцию csrf веб-фреймворка.

Для аутентификации JWT токен может храниться в файле cookie или локальном хранилище. Рекомендуется иметь локальное хранилище, чтобы полностью избежать атак CSRF.

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

  • 1/ JWT — это кодировка открытого текста.Кодировка JWT представляет собой кодировку открытого текста Base64, которую можно декомпилировать. При использовании JWT для передачи информации не размещайте важную конфиденциальную информацию, лучше всего использовать https.
  • 2/ Проблема с утечкой JWTРешение проблемы утечки JWT — это балансирование. Существует три метода обработки от легкого до тяжелого, в зависимости от важности вашего бизнеса:
    • Установите время истечения срока действия JWT настолько коротким, чтобы не имело значения, произойдет ли утечка.
    • Разработайте механизм черного списка JWT на стороне сервера и добавьте утечку токена в черный список.
    • Сохраните выпущенный JWT. При утечке JWT настройка будет недействительной напрямую.

представление

Схема Session-Cookie, поскольку серверная служба хранит информацию о сеансе, должна запрашиваться во время аутентификации, что очень ресурсоемко при большом количестве аутентификаций. JWT может поместить информацию в токен, нужно только проверить декодирование, использовать подпись для проверки токена, и эффективность будет относительно улучшена.

Из вышеперечисленных трех аспектов мы проанализировали преимущества и недостатки методов Session-Cookie и JWT, а также некоторые решения проблем. Я верю, что у каждого будет свой выбор.

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

Когда применяется схема аутентификации Session-Cookie:

  • У проекта есть только веб-сторона;
  • Конфигурация персонала проекта небольшая, и будет задействована как фронтенд, так и бэкенд разработка;
  • Внешняя и внутренняя части проекта не полностью разделены, и передняя часть использует внутреннюю веб-инфраструктуру в качестве сервисного контейнера для запуска;

При использовании схемы аутентификации JWT:

  • Кадровый состав проекта достаточен, разделение труда четкое;
  • Помимо веб-терминала, в проекте есть и мобильный терминал;
  • требования временной авторизации;
  • Взаимодействие между чистыми бэкэнд-системами.

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

Справочник и расширенное чтение

Категории