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

  • Код основного приложения
  • Базы данных (Postgres или MongoDB, например)
  • Хранилище файлов (S3 API)
  • Кеш (Redis)
  • API GW (Caddy или NGINX)
  • Auth-провайдеры (подробнее ниже)
  • Часть приложения работающая с пользователями, организациями, тарифными планами, доступами (назовем клиентский микросервис)

Почему имеет смысл выделить клиентский микросервис сразу же?

  1. Скорее всего, у вас несколько проектов. И такой микросервис будет иметь один и тот же (или очень похожий) код. Другими словами – эффективное переиспользование.
  2. Т.к. это основа безопасности, то лучше его обновлять реже и более осмысленно.

Что такое Auth-провайдеры и зачем они нужны?

В нашем клиентском микросервисе мы не занимаемся полноценной реализацией Auth-протоколов, это делают готовые сторонние микросервисы. Мы же не реализуем БД в своем приложении? Пора и auth в своем приложении не заниматься.

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

Схема взаимодействия:

  1. APIGW (Caddy/NGINX) принимает запрос, работает с https и статикой
  2. Auth proxy – авторизуется и добавляет заголовки
  3. Identity provider – собственно авторизует (и хранит пароли). Может быть Google. А может быть внутренний. Для Google мы внешнее приложение в их настройках.
  4. User service – какой-то внутренний микросевис, который по user id выдает дополнительную информацию (профиль).

Варианты

Для админов:

  • https://oauth2-proxy.github.io/oauth2-proxy/ – добавьте аутентификацию через OAuth2-провайдера (Яндекс, VK и другие) в ваше приложение. В итоге, если все хорошо, то приложение получит заголовки с данными авторизированного пользователя в каждом запросе (например X-Auth-Request-User, X-Auth-Request-Groups, X-Auth-Request-Email, X-Auth-Request-Preferred-Username). Основной сценарий использования – защита внутренних приложений, для SAAS подходит плохо, т.к. не возможности выбирать разных OAuth2-провайдеров.
  • https://github.com/lyang/saml-proxy – Как предыдущее, только SAML (для PingId, Okta, OneLogin и тд)
  • https://www.authelia.com/ – подключаем LDAP и второй фактор.
  • https://www.keycloak.org/ – довольно мощно, но и тяжелый

Далее для разработчиков своих решений.

Прокси:

  • https://github.com/ory/hydra – Compared to other OAuth2 and OpenID Connect Providers it does not implement its own user database and management (for user login, user registration, password reset, 2fa, …), but uses the Login and Consent Flow to delegate rendering the Login UI (“Please enter your email and password”) and Consent UI (“Should application MyDropboxDownload be allowed to access all your private Dropbox Documents?”) to an external application.

Identity provider:

Разное (не понравилось по разным причинам, но это лишь мое мнение на сейчас):

Облачные варианты:

  • Auth0 – этот хорош, но дорог
  • Firebase – вполне популярен для мобильных приложений

В итоге, понравилось https://casdoor.org/ & https://casbin.org/ :

  • open source
  • от крупной компании для которой это не продукт
  • весь какой можно придумать функционал
  • из минусов: общение JWT-токенами в самом приложении, а не на api gw проверка и отдача заголовков – решается через https://github.com/CSU-OSA/Akashic-auth (у самого проекта заведен тикет – https://github.com/casdoor/casdoor/issues/2001 )