Как создать решение для управления пользователями с помощью ORY Oathkeeper и Auth0

Создание решения для управления пользователями с использованием ORY Oathkeeper и Auth0

Что мы делаем?

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

Мы используем комбинацию Auth0, широко используемого для управления пользователями, и ORY Oathkeeper, решения с открытым исходным кодом.

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

Отказ от монолитных функций входа

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

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

Используя существующие решения

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

Требования к решению для аутентификации

API без сохранения состояния и хранилище сеансов

Решение, позволяющее сохранить все наши серверные службы без состояния и сохранить состояние сеанса пользователя вне логики приложения.

Авторизоваться

Пользователи, входящие в приложение, получат подписанный токен JWT и вернутся во внешний интерфейс, сохраненный в файле cookie (или localStorage) и переданный вверх по течению.

Текущие запросы

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

Управление пользователями

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

• Интерфейс и функциональность входа и регистрации

• Вход в систему через OAuth2, совместимый с OIDC.

• Вход через имя пользователя и пароль

• Подтверждение электронной почты и сброс пароля

• Совместимость с OpenID с подписью токена

• При входе в систему мы получаем токен JWT от Auth0 с настраиваемым сроком действия и метаданными.

• Встроенное соответствие требованиям безопасности ссылка

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

Хранитель клятвы

Oathkeeper — это прокси, который поддерживает множество функций аутентификации и авторизации. Он имеет множество функций для поддержки сеансов и позволяет нам аутентифицировать, изменять и маршрутизировать запросы до достижения бизнес-логики:

• Прокси, управляемый конфигурацией

• Аутентификаторы (поддержка JWT, получение файлов cookie из другого сервиса, самоанализ oauth2)

• Авторизаторы (правила управления доступом на основе маршрутов или удаленных служб)

• Мутаторы (настройка заголовков или файлов cookie на основе информации о сеансе или обновление сеанса с помощью удаленной службы)

• Обработка ошибок

• Маршрутизация (проксирование запросов к микросервисам)

• Нативная поддержка Kubernetes через свой контроллер и пользовательские ресурсы

Общий обзор настройки

Краткое объяснение настройки с нуля:

• Облачная инфраструктура на Kubernetes

• Вход

• Прокси-сервер маршрутизации (Oathkeeper позволяет направлять запросы к конечным точкам аутентификации, защищая остальные конечные точки, сохраняя запрос в том же домене, чтобы упростить управление файлами cookie и CORS)

• Auth0 (служба идентификации пользователя и хранилище)

• Обработка сеансов (Oathkeeper использует [аутентификатор JWT] (https://www.ory.sh/oathkeeper/docs/pipeline/authn/#jwt) для управления и проверки сеансов)

• Конечные точки аутентификации для обработки обмена токенами

• Бэкенд-приложение

• Фронтенд-приложение

Топология установки следующая:

Поток входа и поток запроса

Настройка Auth0

В нашем случае мы настроили Auth0 в соответствии с [обычным потоком веб-приложения] (https://auth0.com/docs/flows/add-login-auth-code-flow). При отправке запроса на авторизацию мы должны указать область действия openId. Затем Auth0 вернет токен ID при получении userInfo, который в этом примере является токеном пользователя. Таким образом, нам не нужно поддерживать, менять или развертывать набор закрытых или открытых ключей, реализовывать код для подписи или проверки токенов JWT или выяснять, как защитить учетные данные пользователя или сеансы в вашей базе данных.

Настройка прокси (присяги)

В прокси нам нужно настроить три части:

Маршрутизация

Здесь мы хотим разделить аутентифицированные маршруты и маршруты для входа через «Правила» в Oathkeeper. Контроллер Oathkeeper (oathkeeper-maester) подберет «Правила», применяемые к kubernetes, а затем автоматически применит их к конфигурации Oathkeeper.

Создание сеанса (аутентификатор JWT)

Удобно, что Oathkeeper имеет набор плагинов для обработки распространенных методов аутентификации. Мы используем id_token от Auth0 в качестве токена и проверяем его с помощью [аутентификатора JWT] (https://www.ory.sh/oathkeeper/docs/pipeline/authn/#jwt), настроив подключаемый модуль JWT следующим образом:

Запросить мутацию

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

Развертывание

Мы развертываем Oathkeeper в нашей инфраструктуре с помощью Helm charts через Terraform, но вы можете также разверните его с помощью обычных файлов манифеста kubernetes.

Где `files/oathkeeper-values.yml` будет следовать этот шаблон.

Служба авторизации

Вам нужно будет реализовать несколько конечных точек для обработки взаимодействий с Auth0. Обратите внимание, что вы также можете реализовать их в своем бэкэнд-приложении и направить их в одно и то же место, но для ясности логика представлена ​​в виде отдельного сервиса:

Войти [docs]

• Обменный токен [docs]

• Выход [docs]

В случае успеха все три метода перенаправят пользователя обратно в ваше внешнее приложение.

Бэкэнд-сервис

Чтобы внешний интерфейс определял, вошел ли пользователь в систему или нет, мы можем реализовать конечную точку, например /whoami, которая проверяет заголовки, введенные Oathkeeper, и возвращает информацию о пользователе. Затем вы можете создавать вызовы API без сохранения состояния, которые проверяют статус входа пользователя в систему во внешнем интерфейсе и используют Auth0 в качестве контроллера состояния входа в систему.

Вот пример в node.js. У вас может быть промежуточное ПО для поиска пользователя, например:

Внешний интерфейс

Логин: Чтобы войти в систему, вы можете просто перенаправить пользователя на `/auth0/login`, и он перенаправит вас на страницу входа Auth0, а затем вернет вас обратно в ваше приложение с установленным файлом cookie.

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

Вывод

Oathkeeper — полезный инструмент с открытым исходным кодом, который можно интегрировать с Auth0 для создания элегантного решения для разделения аутентификации пользователя и логики приложения. Такой подход позволяет быстро создавать дополнительные службы, использующие настройку аутентификации пользователя. Рассмотрите этот метод при создании вашего следующего приложения!

Дэвид Чунг является инженерным партнером Commit. Он занимается разработкой программного обеспечения более десяти лет, оттачивая свой опыт в разработке полного стека, и увлечен проектами с открытым исходным кодом.

Также опубликовано [Здесь] (https://blog.commit.dev/articles/open-source-sundays-building-a-user-management-solution-using-ory-oathkeeper-and-auth0)