Серия статей об аутентификации (Часть 1): Практики разработки приложений

Введение

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

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

1. Cookie & Session: Этот традиционный механизм аутентификации широко используется в веб-приложениях, в основном в браузерах. Он проверяет идентификацию пользователя и поддерживает состояние сессии с помощью cookies и сессий.

2. Bearer Token: Это более современный механизм аутентификации, который устраняет зависимость от cookies браузера и вместо этого использует протокол HTTP для аутентификации. Он особенно подходит для сценариев API и может использоваться в мобильных приложениях.

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

Традиционные веб-приложения

Раньше мы использовали Java JSP для создания веб-приложений, идентифицируя пользователей с помощью JSESSIONID, идентификатора сессии, хранящегося в cookie на стороне клиента и передаваемого с каждым запросом.

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

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

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

Эволюция веб-приложений: Отделение фронтенда от бэкенда

С появлением новых фронтенд-технологий, таких как Vue и React, взаимодействие в вебе претерпело революцию. Раньше пользователям приходилось заполнять и отправлять формы на веб-страницах, взаимодействуя с бэкендом с помощью HTML-форм и кнопок, что не обеспечивало плавного пользовательского опыта. Теперь взаимодействие на странице происходит в реальном времени, и разработчики используют JavaScript-скрипты для взаимодействия с API бэкенда, предлагая более последовательный и непрерывный опыт. Взаимодействие пользователей перешло от прямых HTTP-запросов к вызову различных API.

Существуют некоторые различия в механизмах аутентификации идентификации между приложениями, ориентированными на веб-страницы, и приложениями, ориентированными на API. Хотя старые cookies всё ещё можно использовать, они не подходят для современных фронтенд-технологий. Новые технологии дают разработчикам более выразительный код, позволяя выполнять больше операций, включая сценарии, где нам может потребоваться переключение учетных записей пользователей на фронтенде. Однако реализация этого напрямую на фронтенде через cookies является сложной задачей (по соображениям безопасности cookies, связанные с идентификацией пользователя, часто настраиваются как httpOnly, что предотвращает чтение и манипулирование ими JavaScript-скриптами).

Обычно современные фронтенд-приложения сами управляют сессиями пользователей. После успешного входа пользователя фронтенд управляет токеном, сгенерированным бэкендом, и добавляет его в заголовок запроса при вызове API, чтобы бэкенд мог идентифицировать пользователя. API используют токены для идентификации информации о пользователе. Существуют различные технические средства, такие как ручная реализация механизмов токенов с использованием JSON Web Tokens (JWT). Полезная нагрузка JWT хранит идентификационную информацию, такую как ID пользователя, которая затем подписывается, чтобы бэкенд мог проверить токен и извлечь информацию о пользователе.

Однако у JWT также есть некоторые недостатки, такие как:

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

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

К счастью, теперь существуют новые спецификации JWT, которые устраняют эти недостатки. Полезная нагрузка JWT может включать поле под названием "jti" для хранения уникального идентификатора JWT, который может быть сохранен в кэше бэкенда для управления жизненным циклом JWT. Кроме того, спецификация JSON Web Encryption (JWE) определяет зашифрованное расширение JWT, которое сочетает преимущества асимметричного и симметричного шифрования, обеспечивая передачу полезной нагрузки в зашифрованном виде для предотвращения утечки.

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

Новые практики фронтенд-технологий, такие как Next.js, постепенно внедряют техники серверного рендеринга в область фронтенда. Это представляет собой новую эволюцию старой парадигмы веб-разработки, объединяя React с бэкенд-программами для дальнейшего улучшения пользовательского опыта. Теперь существует больше библиотек, таких как NextAuth, которые могут помочь разработчикам реализовать аутентификацию с использованием этого механизма, делая процесс аутентификации более удобным для разработчиков.

API-шлюзы и аутентификация идентификации

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

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

API-шлюзы могут помочь нам решить эту проблему, обрабатывая задачи аутентификации и анализа, такие как cookies или токены, и напрямую передавая проанализированную информацию о пользователе в бэкенд-сервисы, уменьшая дублирование работы. Apache APISIX и API7 Enterprise также поддерживают готовую функциональность аутентификации OpenID Connect, помогая пользователям интегрировать службы аутентификации напрямую. Кроме того, API-шлюзы поддерживают реализацию любого механизма аутентификации через скрипты, поэтому даже с пользовательскими механизмами аутентификации они могут быть интегрированы на API-шлюзе, упрощая разработку приложений.

Заключение

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