Учетные данные сертификата клиента OAuth2 и проблема OIDC
Моя компания использует сервер PingFederate для реализации A&A токена Oauth2, а также мы используем аутентификацию на основе сертификата PKI, для которой настроен сервер.
У нас есть веб-API Java Spring Boot Reactive, настроенный для аутентификации с помощью токенов Oauth2. Он реализует поток кода авторизации.
Так вот в чем проблема.
Когда API выполняет вызов сервера Oauth2 для получения кода авторизации, запрос выполняется с использованием сертификата клиента, настроенного для API, а не сертификата пользователя, совершающего вызов. Код возвращается, и я могу использовать его для получения токена доступа и токена удостоверения.
Проблема в том, что токен идентификации содержит утверждения о клиентском приложении, а не о пользователе.
Есть ли способ настроить реактивный API для передачи сертификата пользователя, а не сертификата API?
Я могу настроить API для использования моего личного сертификата пользователя, и он будет возвращать правильный токен идентификации, но мне нужно иметь возможность извлечь сертификат пользователя из агента и передать его вместе с запросом.
Ответы 1
Обычно поток кода авторизации с использованием клиентских сертификатов для аутентификации работает следующим образом:
ЗАПРОС ПЕРЕДНЕГО КАНАЛА
Этот запрос обычно не использует клиентские сертификаты или API. Вместо этого клиент отправляет запрос авторизации в системный браузер, и пользователь каким-либо способом проходит аутентификацию, чтобы идентифицировать себя.
В результате рассчитывается предмет претензии. Субъект сохраняется сервером авторизации, который возвращает код авторизации в ответе на авторизацию.
ЗАПРОС ОБРАТНОГО КАНАЛА
Затем клиент отправляет код авторизации в запросе токена на конечную точку токена сервера авторизации. Канал mTLS можно использовать для подтверждения права собственности на сертификат клиента. Приложение на основе браузера обычно делает это через серверный компонент, который предоставляет сертификат клиента.
Выданные затем токены содержат субъектное утверждение пользователя, даже если серверный компонент предоставил сертификат клиента.
ВАШ ВОПРОС
Из вашего вопроса несколько вещей кажутся немного нестандартными. Может быть, вы могли бы улучшить свой вопрос?
Какой метод используется для аутентификации пользователя? Например, используете ли вы пароли, ключи доступа, собственный метод аутентификации и т. д.? Метод аутентификации — это то, что вычисляет субъект в токенах.
Используете ли вы сертификаты клиента для аутентификации клиента в конечной точке токена или для аутентификации пользователя каким-либо образом в конечной точке авторизации? Если последнее, то большая часть моего ответа потребует обновления.
Вы пытаетесь выполнить двойной переход клиентских сертификатов от клиента к вашему API и к серверу авторизации? Если так, то это не сработает.
Почему ваш API инициирует поток кода? Это бэкэнд для фронтенда? Как работает запрос фронтального канала? Например. API перенаправляет браузер?
ПРЕДОСТАВЛЕНИЕ СЕРТИФИКАТОВ УРОВНЯ ПОЛЬЗОВАТЕЛЯ
Если вам необходимо развернуть сертификаты клиента на уровне пользователя, ваш API не обеспечивает значительной роли безопасности для внешнего интерфейса. Вместо этого есть несколько вариантов решения, которые вы можете рассмотреть.
ПРЯМОЙ ВЗАИМНЫЙ TLS
Приложение на основе браузера может напрямую вызывать конечную точку токена сервера авторизации с сертификатом клиента. Если сервер авторизации размещен за шлюзом API, вам необходимо настроить шлюз на использование сквозной передачи TLS.
ВЗАИМНЫЙ TLS ПРЕКРАЩЕН НА ПРОКСИ
Если сервер авторизации размещен за шлюзом API, шлюз может проверить сертификат, отправленный приложением на основе браузера, а затем вызвать сервер авторизации. Затем вам необходимо убедиться, что злоумышленник не сможет получить доступ в обход шлюза.
Что ж, я обновил свой ответ, но ваш сценарий непрост, поэтому вам сложно дать точный ответ. Посмотрите, помогут ли мои комментарии.
Гэри Арчер, Спасибо за предоставленную информацию. Я начну рассматривать вариант mTLS более подробно.
Гэри Арчер, это во многом соответствует тому, что мы пытаемся сделать, но включает сертификаты уровня пользователя для аутентификации. Токен идентификатора имеет утверждение субъекта, но оно зависит от переданного сертификата. Если я настрою API для использования сертификата уровня пользователя, утверждение субъекта действительно представляет пользователя. Если я настрою API для использования сертификата клиентского приложения, он будет представлять приложение, а это не то, что мне нужно.