Где должна происходить аутентификация — в gateway или в сервисах?

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

Почему аутентификация в Gateway — предпочтительный подход

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

• Централизация: Вся логика проверки токенов (JWT), сессий или API-ключей находится в одном месте, что упрощает обновление и аудит.
• Производительность: Внутренние сервисы избавляются от накладных расходов на повторную проверку подписи токена для каждого запроса.
• Согласованность: Все сервисы получают запросы, уже прошедшие проверку, что уменьшает риск ошибок из-за разной реализации аутентификации.

Как это работает на практике

После успешной аутентификации Gateway извлекает из токена идентифицирующую информацию (например, user ID, roles) и добавляет её в HTTP-заголовки запроса (например, X-User-Id, X-User-Roles). Эти заголовки затем передаются внутренним сервисам. Сервисы доверяют этим данным, потому что Gateway находится в доверенной сети (за периметром безопасности). Для дополнительной безопасности можно использовать взаимный TLS (mTLS) между Gateway и сервисами.

Пример кода (упрощенный Gateway middleware)

// Псевдокод middleware в API Gateway (например, на Node.js + Express)
async function authMiddleware(req, res, next) {
    const authHeader = req.headers['authorization'];
    if (!authHeader) {
        return res.status(401).json({ error: 'Token required' });
    }
    const token = authHeader.replace('Bearer ', '');
    try {
        // Верификация JWT токена
        const decoded = jwt.verify(token, process.env.JWT_SECRET);
        // Добавляем идентификатор пользователя в объект запроса
        req.user = { id: decoded.userId, roles: decoded.roles };
        // Прокидываем эти данные в заголовках для downstream-сервисов
        req.headers['x-user-id'] = decoded.userId;
        req.headers['x-user-roles'] = JSON.stringify(decoded.roles);
        next(); // Передаем запрос дальше (в прокси или конкретный сервис)
    } catch (err) {
        return res.status(403).json({ error: 'Invalid token' });
    }
}

Роль внутренних сервисов

Сервисы не выполняют полную аутентификацию, но они должны проводить авторизацию — проверять, имеет ли пользователь с данным ID и ролями право на выполнение операции. Они читают заголовки (например, req.headers['x-user-id']) и используют эти данные в бизнес-логике.

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