Аутентификация приложений

Аутентификация приложений развёртывает прокси forward-auth перед Traefik-роутером. Каждый запрос к защищённому домену проходит через прокси: неаутентифицированные пользователи перенаправляются на страницу входа вашего OIDC-провайдера, аутентифицированные сессии передаются в приложение.

Forward auth применяется только к доменам, маршрутизируемым через Docker/Swarm (приложения и compose-стеки); на Kubernetes ingress это не влияет — переключатель не имеет эффекта для приложений, развёрнутых на Kubernetes.

Как это работает

1. На целевом сервере разворачивается лёгкий контейнер auth-прокси.
2. Middleware forwardAuth Traefik добавляется к каждому домену, который нужно защитить.
3. Неаутентифицированные запросы перенаправляются к OIDC-провайдеру.
4. После входа провайдер выполняет обратный редирект через домен аутентификации, а прокси устанавливает cookie сессии.
5. Последующие запросы содержат cookie и передаются напрямую в приложение.

Предварительные требования

• План Enterprise с включённой функцией SSO
• SSO-провайдер с настроенным OIDC (SAML-провайдеры не поддерживаются для аутентификации приложений)
• Домен для самого прокси (например, auth.example.com)
• На облачном плане: необходимо выбрать удалённый сервер; локальное развёртывание недоступно
• Защищаемый домен должен иметь тот же базовый домен, что и домен аутентификации — cookie сессии устанавливается на базовый домен домена аутентификации, поэтому домен аутентификации auth.example.com может защищать только домены в рамках example.com (например, app.example.com, но не app.other.com)

Развёртывание прокси

1. Перейдите в Settings → SSO → Application Authentication.
2. Выберите целевой Сервер (пользователи облачного плана должны выбрать удалённый сервер).
3. Выберите SSO-провайдер — в списке отображаются только OIDC-провайдеры.
4. Укажите Auth Domain — это имя хоста, которое прокси использует для своего колбэка (auth.example.com). Должно быть корректным именем хоста и указывать на тот же сервер. Настройте DNS-запись A этого домена на IP-адрес сервера — подсказка с адресом отображается на странице.
5. Нажмите Deploy proxy.

Прокси считывает OIDC issuer, client ID и client secret непосредственно из сохранённого SSO-провайдера — они никогда не отображаются в интерфейсе. Под капотом Skitflow разворачивает oauth2-proxy как сервис Docker Swarm (skitflow-oauth2-proxy-<server>), закреплённый за manager-узлом, вместе с Traefik-роутером websecure и сертификатом Let's Encrypt для домена аутентификации.

Защита домена

После развёртывания откройте любой домен приложения или compose-стека и включите переключатель Protect with SSO. Для этого требуется развёрнутый прокси на сервере приложения и домен с тем же базовым доменом, что и у прокси (см. предварительные требования). Передеплойте приложение, чтобы применить изменение. Для приложений конфигурация применяется немедленно; для compose-стеков — при следующем деплое.

Проверка статуса прокси

Статус прокси отображается на странице настроек Application Authentication. Его также можно запросить напрямую:

GET /api/trpc/forwardAuth.status?input={"serverId":"<server-id>"}

Возвращает состояние реплик сервиса Swarm:

{ "running": true, "replicas": 1 }

Удаление прокси

1. Перейдите в Settings → SSO → Application Authentication.
2. Нажмите Remove.

Перед удалением сервиса прокси Skitflow автоматически снимает флаг forwardAuthEnabled с каждого защищённого им домена, чтобы ни одно приложение не осталось указывающим на удалённую точку аутентификации. Для приложений конфигурация Traefik перерисовывается немедленно, поэтому middleware удаляется сразу. Домены compose-стеков теряют middleware при следующем деплое.

Справочник API

Все эндпоинты требуют токен сессии администратора.

Тело запроса deploy

{
  "serverId": "<server-id-or-null>",
  "ssoProviderId": "<oidc-provider-id>",
  "authDomain": "auth.example.com"
}

Целевой объект (status / getServerConfig / remove)

{
  "serverId": "<server-id-or-null>"
}

Передайте null в serverId для указания на локальный сервер платформы (только для self-hosted).