определение существительного
- Стороннее приложение: стороннее приложение, также известное в этой статье как «клиент».
- Служба HTTP: поставщик службы HTTP, именуемый в этой статье «поставщик службы».
- Владелец ресурса. Владелец ресурса, также известный как «пользователь» в этой статье, — это вошедший в систему пользователь.
- Пользовательский агент: пользовательский агент, в этой статье речь идет о браузере.
- Сервер авторизации: Сервер аутентификации, то есть сервер, специально используемый поставщиком услуг для обработки аутентификации.
- Сервер ресурсов: Сервер ресурсов, то есть сервер, на котором поставщик услуг хранит ресурсы, созданные пользователем. Он и сервер аутентификации могут быть одним сервером или другим сервером.
История исследований и разработок
Когда количество систем корпоративных приложений постепенно увеличивается, каждая система управляет своими пользовательскими данными отдельно, что позволяет легко сформировать информационный остров, а модель децентрализованного управления пользователями препятствует развитию корпоративных приложений на платформе. Когда интернет-бизнес предприятия развивается до определенного масштаба, важно создать унифицированную и стандартизированную систему управления учетными записями, поскольку это важная инфраструктура корпоративной облачной интернет-платформы, которая может обеспечить унифицированное управление учетными записями, аутентификацию удостоверений, авторизацию пользователей и другие базовые возможности предоставляют предприятиям базовые возможности, такие как межсистемный единый вход и вход в систему с авторизацией третьей стороны, обеспечивая необходимые условия для создания открытой платформы и бизнес-экосистемы.
В системе монолитных приложений приложение представляет собой единое целое, и проверка разрешений обычно выполняется для всех запросов. Запрос обычно проверяется перехватчиком разрешений, информация о пользователе кэшируется в сеансе при входе в систему, а информация о пользователе извлекается из кеша для последующих обращений.
С появлением Restful API и микросервисов аутентификация на основе токенов становится все более распространенной. Токен отличается от идентификатора сеанса, а не просто от ключа. Токен обычно содержит соответствующую информацию о пользователе, и проверка личности может быть завершена путем проверки токена.
Преимущества аутентификации на основе токенов заключаются в следующем:
- На стороне сервера без сохранения состояния: механизму токена не нужно хранить информацию о сеансе на стороне сервера, поскольку сам токен содержит всю информацию, относящуюся к пользователю.
- Производительность выше, поскольку больше нет необходимости обращаться к базе данных или удаленному сервису для проверки разрешений при проверке токена, что, естественно, может значительно повысить производительность.
- Поддерживает мобильные устройства, поддерживает межпрограммные вызовы, куки не разрешают доступ с битых доменов, а у Токена этой проблемы нет.
Цели НИОКР
С помощью стандартного процесса сертификации безопасности гетерогенные системы или кросс-сервисы могут гибко реализовать интеграцию и унифицированную сертификацию безопасности определенных функциональных компонентов или сервисов.
- Типичный процесс, основанный на аутентификации с помощью токена, выглядит следующим образом:
- Пользователь вводит информацию для входа (или вызывает интерфейс Token и передает информацию о пользователе) и отправляет ее службе аутентификации для аутентификации (служба аутентификации может быть вместе с сервером или может быть отделена, в зависимости от разделение микросервиса).
- Служба аутентификации проверяет правильность информации для входа и возвращает интерфейс (как правило, интерфейс будет содержать такую информацию, как основная информация о пользователе, область разрешений, время действия и т. д.), а интерфейс хранилища клиента может быть сохранен в сеансе. или базу данных.
- Клиент помещает токен в заголовок HTTP-запроса и инициирует соответствующие вызовы API.
- Вызываемая микрослужба проверяет разрешение токена.
- Сервер возвращает связанные ресурсы и данные.
Функциональная точка аутентификации безопасности
- Чтобы получить учетные данные, клиент стороннего приложения использует код клиента/код безопасности, имя пользователя/пароль владельца ресурса и другую учетную информацию для получения учетных данных доступа к ресурсу токена доступа с сервера авторизации.
- Авторизация входа, клиент несет учетные данные токена доступа для доступа к ресурсам сервера, сервер ресурсов проверяет токен, учетную информацию стороннего приложения и законность пользователя-владельца ресурса, считывает идентификационную информацию владельца ресурса (пользователя) через Token и загружает элементы разрешений владельца ресурса. Выполните вход.
- При аутентификации доступа клиент стороннего приложения получает доступ к ресурсам сервера, система проверяет действительность маркера доступа посетителя, информацию о разрешениях и правильность учетных данных (токен доступа). В это время сервер ресурсов возвращает информация о ресурсах.
- Обновление учетных данных: по истечении срока действия токена доступа необходимо обновить учетные данные, чтобы обновить срок действия учетных данных токена.
Анализ выбора технологии
- Системная авторизация использует стандартный режим пароля открытой авторизации OAuth2.
- Токен принимает стандарт JWT.
1. Открытая авторизация OAuth
OAuth (открытая авторизация) определяет безопасный, открытый и простой стандарт для авторизации пользовательских ресурсов.Третья сторона может получить информацию об авторизации пользователя, не зная его учетной записи и пароля.
Существует четыре основных метода авторизации:
-
Режим кода авторизации (код авторизации) используется для авторизации кодов между клиентскими и серверными приложениями.
-
Упрощенный режим (неявный) используется в мобильных приложениях или веб-приложениях (эти приложения находятся на устройстве пользователя, например, вызов WeChat на мобильном телефоне для аутентификации и авторизации). Вместо того, чтобы проходить через сервер стороннего приложения, подайте заявку на токен с сервера аутентификации прямо в браузере, пропустив шаг «код авторизации», отсюда и название. Все шаги выполняются в браузере, токен виден посетителю, а клиент не требует аутентификации.
-
Режим пароля (учетные данные владельца ресурса) Приложениям доверяют напрямую (оба разработаны компанией) В режиме пароля пользователь предоставляет клиенту свое имя пользователя и пароль. Клиент использует эту информацию для запроса авторизации у «поставщика услуг». В этом режиме пользователь должен сообщить свой пароль клиенту, но клиент не должен хранить пароль.
-
Учетные данные клиента используются в клиентском режиме доступа к API приложения (Предоставление учетных данных клиента) означает, что клиент проходит аутентификацию у «поставщика услуг» от своего имени, а не от имени пользователя. Строго говоря, клиентский режим не является частью проблемы, которую призван решить фреймворк OAuth. В этом режиме пользователь регистрируется напрямую у клиента, а клиент запрашивает у «поставщика услуг» предоставление услуг от своего имени, по сути проблемы с авторизацией не возникает.
2. Json web token (JWT)
Веб-токен Json (JWT) — это открытый стандарт на основе JSON ((RFC 7519), реализованный для передачи утверждений между средами веб-приложений. Токен спроектирован так, чтобы быть компактным и безопасным, особенно для одноразовых распределенных сайтов. Сценарий SSO). Объявления JWT обычно используются для передачи аутентифицированной информации об удостоверении пользователя между поставщиками удостоверений и поставщиками услуг для получения ресурсов от серверов ресурсов, а также могут добавлять некоторую дополнительную другую необходимую бизнес-логику. непосредственно для аутентификации, или он может быть зашифрован.
Логика процесса аутентификации
1. Авторизация системы
Клиент стороннего приложения использует код клиента/код безопасности, имя пользователя/пароль владельца ресурса и другую учетную информацию для получения учетных данных доступа к ресурсу маркера доступа с сервера авторизации.
Системная авторизация выдается клиентскому приложению Access Token
2. Аутентификация системы
Клиент получает доступ к ресурсам сервера с учетными данными токена доступа. Сервер ресурсов проверяет легитимность токена, стороннего приложения и пользователя-владельца ресурса, считывает идентификационную информацию владельца ресурса (пользователя) через токен и загружает полномочия владельца ресурса для входа в систему.
Система проверяет действительность и информацию о полномочиях токена доступа посетителя, а также проверяет правильность токена доступа.В это время сервер ресурсов возвращает информацию о ресурсе.
3. Обновление учетных данных
По истечении срока действия токена доступа необходимо обновить сертификат, чтобы обновить срок действия сертификата токена.
дизайн интерфейса
1. Учетные данные авторизации
Получите учетные данные для авторизации, проверьте информацию об удостоверении клиента, проверьте информацию об удостоверении владельца ресурса и выдайте учетные данные токена.
Код клиента/защитный код должен быть сгенерирован сторонним приложением после подтверждения регистрации системы.
2. Обновление сертификата авторизации
Получите сертификат авторизации продления, проверьте информацию об удостоверении клиента, проверьте сертификат RefreshToken и выдайте сертификат Token.