Две или три вещи о внешней и внутренней аутентификации

внешний интерфейс
Две или три вещи о внешней и внутренней аутентификации

DevUI – это команда, которая занимается как проектированием, так и проектированием, обслуживая HUAWEI CLOUD.DevCloudПлатформа и несколько промежуточных и серверных систем в Huawei предназначены для дизайнеров и проектировщиков.
Официальный сайт:devui.design
Библиотека компонентов Ng:ng-devui(Добро пожаловать в Звезду)
Официальное сообщение: добавление помощника DevUI (официальный devui)
Плагин DevUIHelper: DevUIHelper-LSP (Добро пожаловать в Star)

少东.png

введение

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

1 Аутентификация и авторизация

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

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

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

Авторизация

Авторизация включает два приложения и одного пользователя и используется для описания того, какие разрешения на операции есть у стороннего приложения.

Добавление сцены для различения аутентификации и авторизации

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

(1) Только аутентификация без авторизации

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

(2) Аутентификация и авторизация

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

(3) Нет аутентификации, только авторизация

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

2 Каковы наиболее часто используемые методы аутентификации и авторизации?

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

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

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

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

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

Токен аутентификации

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

SAML (Security Assertion Markup Language)

1.jpg

Поток SAML выглядит следующим образом:

  • Незарегистрированные пользователи получают доступ к веб-сайту ресурса (сокращенно «Поставщик услуг», SP) через браузер.
  • SP обнаруживает, что пользователь не вошел в систему, и перенаправляет страницу IdP (поставщику удостоверений).
  • После того, как IdP подтвердит правильность запроса, предоставьте пользователю форму для входа в систему.
  • После успешного входа пользователя IdP создает и отправляет токен SAML (большой XML-объект) в SP.
  • SP проверяет токен, анализирует и получает информацию о пользователе, а также позволяет пользователям получать доступ к связанным ресурсам.

Два дополнительных пункта информации для вышеуказанного процесса:

(1) Как SP проверяет легитимность токена?

Например, возможно ли, что токен был украден, а содержимое было изменено в процессе перехода от IDP к SP?

Ответ: невозможно. Поскольку токен, возвращаемый IDP поставщику SP, подписан закрытым ключом IDP, а информация, подписанная закрытым ключом, может быть проверена соответствующим открытым ключом.

(2) Как SP определяет, истек ли срок действия токена?

Токен SAML содержит информацию о сроке действия токена.

(3) Размещен ли сгенерированный токен SAML на SP или на внешнем интерфейсе?

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

Ответ: оба. Если он размещен во внешнем интерфейсе, переднему концу необходимо получить токен через отдельный запрос ajax и сохранить его в localStorage или другом локальном хранилище. Если он размещен на SP, как упоминалось выше, сеанс вводится, а внешний интерфейс получает только sessionId.В этом случае механизм токена фактически вырождается в упомянутый выше механизм сеансовых файлов cookie.

JWT (веб-токен JSON)

Есть много статей о JWT, которые не будут здесь повторяться.Начало работы с веб-токеном JSON(Расчетное время чтения: 2 минуты)

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

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

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

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

См. это предложение из вводного документа официального введения JWT:

The signature is used to verify the message wasn't changed along the way, and, in the case of tokens signed with a private key, it can also verify that the sender of the JWT is who it says it is.

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

Есть интересная картинка про сравнение JWT и SAML

2.jpg

3.jpg

OAuth-авторизация

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

Эта статья ориентирована на аутентификацию, и протокол OAuth здесь не слишком подробно обсуждается. Дополнительную информацию об OAuth см. в этой статье:Понимание OAuth 2.0

3 единого входа и клиентского доступа

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

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

В области единого входа часто используется CAS (Центральная служба аутентификации, китайское название — Центральная служба аутентификации). Поэтому здесь представлено введение в реализацию единого входа с помощью CAS. Конкретная реализация CAS может опираться на многие протоколы, такие как OpenID, OAuth, SAML и т. д. Здесь мы сосредоточимся на протоколе CAS.

Несколько важных концепций протокола CAS

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

  • CAS Server: центральный сервер для аутентификации

  • Клиенты CAS: защита приложений CAS и перенаправление на сервер CAS для аутентификации при доступе пользователей, не прошедших проверку подлинности.

  • TGT и TGC: после аутентификации пользователя сервер CAS создает TGT (билет на предоставление билетов), содержащий информацию о пользователе, и записывает в браузер файл cookie (TGC, файл cookie для предоставления билетов).

  • ST: Билет, переданный в качестве параметра URL-адреса, защищенное приложение может использовать этот билет для перехода на сервер CAS, чтобы подтвердить, является ли аутентификация пользователя законной.

Основной процесс протокола CAS

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

4.jpg

5.jpg

① Пользователь получает доступ к домашней странице защищенного приложения (далее app_1) через браузер

② Клиент CAS на стороне приложения_1 определяет, что пользователь не прошел аутентификацию, путем обнаружения сеанса и перенаправляет пользователя (первое перенаправление) на сервер CAS. Служба параметров, передаваемая по URL-адресу, содержит адрес доступа приложения_1.

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

  • TGC связан с TGT, и браузер пользователя напрямую получает билет ST с сервера CAS.Если TGC действителен, пользователю не нужно выполнять шаги по заполнению информации формы, чтобы напрямую войти в систему.
  • Политика истечения срока действия TGC устанавливается следующим образом. Если у пользователя нет операций со страницами и фоновых запросов интерфейса, срок действия по умолчанию истекает через 2 часа. Если всегда есть операция, срок действия по умолчанию истекает через 8 часов. Разработчики могут установить эти два времени истечения срока действия. в cas.properties внесите изменения, такой большой срок годности не будет настроен в общих приложениях
# most-recently-used expiration policy
cas.ticket.tgt.timeout.maxTimeToLiveInSeconds=7200
# hard timeout policy
cas.ticket.tgt.timeout.hard.maxTimeToLiveInSeconds=28000

④ Сервер CAS для перенаправления браузера (второе перенаправление) app_1 обратно домой, на этот раз с URL-адресом перенаправления ST

⑤ app_1 снова получает доступ к браузеру пользователя, извлекает ST из параметра url на предыдущем шаге и использует ST для перехода на сервер CAS, чтобы подтвердить, завершил ли текущий пользователь аутентификацию.После того, как сервер CAS дает положительный ответ, приложение_1 удаляет браузер перенаправления ST (третье перенаправление) на домашнюю страницу приложения_1

  • app_1 (клиент CAS) получает дополнительную информацию, включая информацию о пользователе, при подтверждении текущего статуса аутентификации пользователя с помощью ST на сервер CAS.
  • Запишите эту дополнительную информацию в сеанс и верните sessionId во внешний интерфейс, после чего передний конец сможет напрямую определить, действителен ли сеанс при следующем доступе.

⑥ Клиентский браузер для доступа к домашней странице app_2 в той же системе аутентификации.

⑦ Как и в шаге ②, клиент CAS на стороне приложения_2 определяет, что пользователь не прошел проверку подлинности, обнаружив сеанс, и перенаправляет пользователя на сервер CAS.Служба параметров, передаваемая в URL-адресе, содержит адрес доступа приложения_2.

⑧ Сервер CAS определяет TGC браузера пользователя и находит соответствующий TGT, который подтверждается как легальный Это повторяет TGC шага 3.

⑨ Как и в шаге 4, сервер CAS перенаправляет браузер обратно на домашнюю страницу app_2, а URL-адрес перенаправления содержит ST

⑩ Как и в шаге ⑤, app_2 снова получает доступ к браузеру пользователя, извлекает ST из параметра url на предыдущем шаге и использует ST для перехода на сервер CAS, чтобы подтвердить, завершил ли текущий пользователь аутентификацию. Сервер CAS дает положительный ответ, app_2 Удалите ST из URL-адреса и перенаправьте браузер на домашнюю страницу app_2.

Несколько вопросов о процессе CAS

(1) Как избежать конфликта sessionId?

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

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

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

После возникновения конфликта, когда пользователь переключается между a и b, клиенты CAS с обеих сторон должны постоянно обращаться к серверу CAS для подтверждения и обновления сеанса. Если описание этого абзаца не легко понять, вы можете открыть и снова прочитать раздел [Первый доступ ко второму приложению] в приведенной выше блок-схеме. На самом деле избежать конфликтов очень просто, а именноa и b добавляют имя службы в качестве префикса к ключу, который они записывают во внешний файл cookie., такие как a_sessionId и b_sessionId соответственно.

(2) Предполагая, что a и b используют один и тот же сервер аутентификации единого входа, возможно ли, что срок действия входа приложения a истек, но срок действия приложения b не истек?

Затем обсудите приведенный выше вопрос, если a и b не используют общий сеанс, возможно ли, что существует такая ситуация: статус аутентификации приложения a истек (и сеанс, и TGC недействительны), а срок действия приложения b не истек (сеанс или ТГК существует хоть один действующий)?

Ответ - нет. В бизнес-реализации клиент CAS будет регулярно связываться с сервером CAS.Если пользователь работал, сервер CAS соответственно продлит срок действия TGC.В конце концов, для a и b,Срок действия ТГК должен быть одинаковым. Следовательно, даже если время истечения срока действия настроек сеанса на обеих сторонах несовместимо, состояние аутентификации можно завершить, самое большее, перейдя на сервер CAS и пройдя обнаружение TGC, и не будет ситуации, когда необходимо войти в систему и b не нужно входить в систему.

Суммировать

В этой статье сначала обсуждается разница между аутентификацией и авторизацией, а также перечисляются несколько распространенных методов аутентификации и авторизации. Затем основное внимание уделяется процессу и проблемам использования протокола CAS для достижения единого входа. Наконец, еще одно добавление. Клиент CAS в HUAWEI CLOUD DevCldoud — это реализация эталонного стандартного протокола CAS.это здесьЗарегистрируйте учетную запись, затем откройте F12 и войдите в систему с учетной записью, чтобы наблюдать за всеми сетевыми запросами и анализировать весь процесс бизнес-реализации CAS.

Присоединяйтесь к нам

Мы команда DevUI, приглашаем вас приехать сюда, чтобы вместе с нами создать элегантную и эффективную систему человеко-машинного проектирования/исследований и разработок. Электронная почта для приема на работу:muyang2@huawei.com.

Текст / DevUI маленький восток

Справочная статья

Рекомендуемые статьи в прошлом

«Хорошо летать! Плагин VSCode DevUIHelper дизайн и стратегия разработки (1)"

«Темный режим веб-интерфейса и разработка тем»

"Научить вас, как создать среду публикации в оттенках серого"

Категории