обновляется на основе вопросов от @ user18044 нижеАутентификация/авторизация веб-API с использованием SSO вместо OAUTH - будет ли она работать?
Если пользователь проходит аутентификацию в двух различных веб-приложений с помощью 2-х различных провайдеров удостоверений SAML на основе, и один из приложений, необходимо запросить данные из веб-API выставленному в другом приложении можно было бы безопасно вызывать методы веб-API в силу текущего аутентифицированного статуса пользователя в обоих приложениях без отдельного обеспечения методов API через протокол аутентификации уровня API, такой как OAUTH? Обратите внимание, что оба приложения принадлежат и управляются моей компанией и используют одни и те же домены уровня 2 и пользовательскую базу, даже несмотря на то, что серверы идентификации отличаются (один из них устарел).
Дополнительная информация: Приложение A представляет собой приложение для портала, которое будет размещать виджеты, используя данные, предоставленные из приложения B. Приложение A будет связываться только с приложением B через веб-API, предоставляемый приложением B. В настоящее время приложение B не раскрывает веб-API (кроме внутреннего для самого приложения). Это новая функциональность, которая должна быть добавлена в приложение B. Приложение A будет использовать Okta в качестве своего SSO. Предложение нашего ведущего архитектора состоит в том, чтобы продолжать использовать пользовательский старый IDP-сервер, который мы разработали внутри, используя dk.nita.saml20 DLL. Я думаю, что они оба основаны на SAML, но я не думаю, что они могли бы использовать один и тот же идентификационный токен без какой-либо модернизации. Но это касается моих знаний по теме аутентификации. :) Я думаю, что план нашего архитектора состоял в том, чтобы пользователь аутентифицировался отдельно, используя два разных поставщика удостоверений, а затем только защищал веб-API с помощью CORS, его рассуждение состояло в том, что, поскольку пользователь уже известен и аутентифицирован для использования приложения B, не будет никаких последствий для безопасности, позволяющих приложению A вызывать методы веб-api приложения B, поскольку пользователь должен быть аутентифицирован в приложении B. Это кажется мне причудливым, поскольку я могу представить много переадресаций браузеров, которые могут быть не прозрачными для пользователя, но кроме этого, я просто пытаюсь выяснить, где могут быть дыры в безопасности, потому что мне кажется, что будут некоторые.
Я знаю, что этот подход не будет считаться лучшей практикой, однако, с учетом сказанного, я действительно хочу понять, почему нет. Имеются ли последствия для безопасности? Будет ли это работать? И если да, есть ли какие-либо «gotchas» или вещи, которые следует учитывать при реализации?
Чтобы повторить, наш ведущий архитектор предлагает это решение, и он не справляется с моей проверкой кишки, но я недостаточно разбираюсь в этой теме, чтобы оправдать свое положение или чувствовать себя достаточно комфортно, чтобы принять его. Надеясь, что некоторые эксперты по безопасности могут просветить меня.
удивительно, если ваш вопрос похож на мой, который я просил на сайте информационной безопасности (о протоколах/подхода в целом, а не о том, как реализовать): HTTP: // безопасность .stackexchange.com/questions/89448/proxy-authentication-to-web-apis-in-sso-environment – wrschneider