Мы стремимся внедрить SSO (внешний пользователь) и шлюз API для поддержки веб-приложений и мобильных приложений, а также потенциально сторонних приложений и даже сценариев B2B.Как объединить аутентификацию на уровне пользователя и клиента на шлюзе API?
Моя мысль заключается в том, чтобы шлюз SSO обрабатывал пользовательский уровень доступа к веб-сайтам и API-интерфейсам, аутентифицируя конечных пользователей с использованием OAuth или OpenID Connect.
За этим, для любых URL-адресов API, является шлюз API. Это предназначено для обработки аутентификации на уровне клиента/приложения, используя что-то вроде идентификатора клиента и секретности.
Идея заключается в том, что пользователь должен войти на сайт или мобильное приложение, а затем, если/когда это приложение необходимо для вызова API ему необходимо будет отправить свои собственные учетные данные (учетные данные клиента потока) а также токен-носитель, подтверждающий, кто является пользователем (поток пароля владельца ресурса).
Учетные данные клиента меньше связаны с безопасностью и более широкими возможностями доступа к функциям API, что обеспечивает видимость использования API, формирование трафика, SLA и т. Д., Но идентификация пользователя необходима для обеспечения авторизации на уровне данных ниже по течению.
Большинство шлюзов API, на которые я смотрел, похоже, поддерживают только один уровень аутентификации, например. мы смотрим на Apigee на данный момент, который может использовать OAuth для аутентификации для работы с пользователем или приложением, но не очевидно, как это сделать одновременно.
Есть ли способ получить токен-носитель пользователя шлюза SSO, чтобы хорошо играть с маркером или учетными документами клиента-шлюза API-шлюза, предпочтительно на основе стандартов? Или нам просто нужно взломать его так, чтобы он проходил через заголовок auth, а другой в полезной нагрузке? Или есть способ иметь комбинированный подход (например, гибридный маркер-носитель), который может одновременно служить обеим целям?
Я очень удивлен тем, что при всей работе, связанной с управлением идентификацией (OAuth2, OpenID Connect, UMA и т. Д.), Никто не смотрит на способ одновременной обработки нескольких уровней аутентификации - пользователя, клиента, устройство и т. д.
Немного любопытно, почему вы думаете, что не можете делать оба в то же время из коробки? – brandonscript
Для уровня клиента я попросил бы токен доступа с URL-адреса Apaut's accautstoken, а затем передал его в заголовке HTTP-авторизации. Однако шлюз SSO также делает аналогичную вещь с именем пользователя (владельца ресурса), и я считаю, что он также пытается передать его в заголовке авторизации. Очевидно, они не могут оба это сделать.Я мог бы прервать шлюз SSO, чтобы помещать токен-носитель пользователя где-то в другом месте (полезная нагрузка или настраиваемый заголовок), но все это кажется очень неэлегантным, и мне было интересно, есть ли какие-либо подходы для объединения обеих концепций в один пользователь + клиентский auth маркер. – ChrisC
В конечном счете было бы неплохо иметь унифицированный токен, содержащий доказательства идентификации пользователя, клиента и устройства в одном аккуратном пакете. Возможно, однажды ... – ChrisC