Механизмы аутентификации в микросервисах

[1.] API-КЛЮЧИ

* Простые уникальные идентификаторы, присваиваемые каждому клиенту или сервису.

* Передаются в заголовке или как параметр запроса с каждым обращением.

* Лучше всего подходят для внутренних сервисов, менее чувствительных API или для предоставления доступа к определённым функциям.

* Простота внедрения и управления.

* Менее безопасны по сравнению с токен-базированными методами. Ключи могут быть легко скомпрометированы или украдены.

[2.] БАЗОВАЯ АУТЕНТИФИКАЦИЯ

* Имя пользователя и пароль передаются в заголовке Authorization в виде строки, закодированной в base64.

* Простота реализации, но для обеспечения безопасности требуется HTTPS.

* Подходит для простых сценариев с низкими требованиями к безопасности.

* Широкая поддержка и простота понимания.

* Уязвимость к атакам типа «человек посередине» (man-in-the-middle), если не используется HTTPS.

* Пароли передаются в открытом тексте (даже при кодировании).

[3.] JSON WEB TOKENS (JWT)

* Автономные токены, содержащие информацию о пользователе и утверждения в полезной нагрузке JSON.

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

* Широко используются для аутентификации без сохранения состояния в микросервисах, единого входа (SSO) и авторизации.

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

* Требуется надлежащее управление ключами для подписи и проверки.

[4.] OAUTH 2.0

* Фреймворк авторизации, позволяющий сторонним приложениям получать ограниченный доступ к ресурсам от имени владельца ресурса (пользователя) без передачи учётных данных.

* Использует различные типы грантов (код авторизации, неявный, учётные данные клиента и т. д.) для получения токенов доступа и обновления.

* Широко применяется для авторизации пользователей и делегированного доступа к API.

* Предоставляет стандартизированный способ защиты доступа к ресурсам без передачи учётных данных.

* Может быть сложным для реализации и требует тщательного рассмотрения уязвимостей безопасности.

[5.] OPENID CONNECT (OIDC)

* Уровень идентификации поверх OAuth 2.0, предоставляющий аутентификацию пользователя и информацию о профиле.

* Использует ID-токен вместе с токеном доступа для предоставления информации об идентификаторе пользователя.

* Применяется для аутентификации в сочетании с OAuth 2.0 для авторизации.

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

* Требует интеграции с провайдером OIDC (например, Google, Okta).

[6.] ВЗАИМНАЯ TLS (mTLS)

* И клиент, и сервер аутентифицируют друг друга с помощью сертификатов X.509.

* Требуется центр сертификации (CA) для выдачи и управления сертификатами.

* Лучше всего подходит для защиты коммуникации между внутренними сервисами или высокочувствительными API.

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

* Более сложная настройка и управление по сравнению с другими механизмами.

Эти механизмы/типы аутентификации не ограничиваются только микросервисами.

Источник: vk.com

Комментарии: