Window.opener и window.parent не работают во всплывающем дочернем окне

В перспективе, можете ли вы создать закадровый iframe в домене z, а затем открыть дочернее окно? Таким образом, дополнительный iframe может передавать сообщения.

Или дочернее окно открыто в одном из других доменов с iframe, установленным на 100vh/100vw? И ретранслировать через это?

Я не на 100% понимаю. Думаю, я понял идею, но не возникнут ли проблемы перекрестного происхождения? @ДэвидБрэдшоу

Я интерпретирую это как создание внутреннего приложения. Я хочу создать приложение, которое будет опубликовано в магазине Teams, чтобы другие могли его загрузить и войти в него с помощью SSO. На самом деле, мне просто нужно убедиться, что этот человек вошел в свою электронную почту, поскольку я создаю волшебную ссылку для входа, на которую он может перенаправить. У меня нет возможности что-либо настраивать для организаций, загружающих это приложение, поэтому я не уверен, что я пытаюсь сделать вкладку sso docs.

Этот механизм единого входа предназначен для обоих сценариев. У меня тоже есть приложение в магазине, использую его. Вам нужно только создать приложение Azure AD в своем собственном клиенте — для других арендаторов оно будет создано автоматически, когда кто-то «согласится» использовать ваше приложение (они нажимают «ОК» во всплывающем окне «согласие», возможно, вы это видели) с другими приложениями или различными типами в M365).

Мне бы хотелось узнать об этом больше. Откроется всплывающее окно с просьбой войти в Microsoft, они входят в систему, используя свою электронную почту Outlook/Live, и получают передаваемый обратно токен аутентификации, подтверждающий их личность. Это заблокировано в электронном письме Outlook, верно? Если они создали учетную запись в моем приложении с помощью Gmail, но у них есть электронная почта Outlook для команд, это не сработает?

Это тот же способ, которым мы получаем доступ к графическому API?

Да, получить токен Graph можно тем же способом — вы можете выполнить поиск по запросу OBO или токена «От имени». Хотя я не следую вашему предыдущему комментарию. Если они используют ваше приложение внутри Teams, вам не нужно беспокоиться о «типе» учетной записи — у них уже есть учетная запись Teams по определению. Как в таком случае они вошли в систему через Gmail?

Мое приложение — это существующее веб-приложение, которое я встраиваю в клиент Teams, поэтому у многих пользователей уже есть учетная запись. Некоторые из них с Gmail. В конечном итоге это может привести к созданию единого удостоверения для пользователя, у которого может быть два адреса электронной почты. Но только один используется в качестве источника правды для входа в учетную запись. Но OBO — это здорово, я хотел бы иметь доступ к календарю пользователя, поэтому мне все равно понадобится доступ к токену Graph API.

На самом деле я решил просто использовать маршрут Microsoft SSO. Я занимаюсь чрезмерным проектированием и воспользуюсь этим. Спасибо!

Окей, звучит хорошо. Вам понадобится дополнительная информация об учетной записи пользователя, но я думаю, что в целом это более простой и правильный путь. Кстати, вам не нужно хранить адрес электронной почты команды как таковой, а скорее свойство AD/Entra Id пользователя (guid).

По сути, я запрашиваю токен аутентификации, и Microsoft предлагает пользователю войти в систему. Если они входят в систему, возвращается токен аутентификации, и это говорит мне, что они аутентифицированы. Но есть ли дополнительный шаг, который я могу предпринять, чтобы подтвердить, что токен предназначен для пользователя?

да, вам обязательно следует проверять токен на своем сервере — подробнее см. здесь, хотя и довольно подробно: Learn.microsoft.com/en-us/entra/identity-platform/… . Проще говоря, вы хотите отправить токен на свой сервер в качестве токена на предъявителя в заголовке Auth, а затем выполнить проверку JWT — он должен соответствовать данным вашего приложения Azure AD («Entra ID»), а также будет содержать пользовательский AadObjectId. и идентификатор арендатора

Таким образом, у пользователей уже может быть учетная запись в моем приложении. Я использую ссылки для входа в систему для входа пользователей. Поэтому, пока токен проверен, мы говорим, что этот пользователь аутентифицирован. Я могу получить их адрес электронной почты (требуется для входа в систему), доверять этому и просто войти в систему? Остальные объекты на самом деле ничего не значат для моего приложения, кроме проверки токена, который мне отправляет MS. Я просто пытаюсь понять это немного лучше, поскольку безопасность немного размыта, и я не уверен на 100%, как я могу просто доверять этому токену аутентификации и регистрировать пользователя в моем приложении.

Я предполагаю, что вы используете Google Sign In в своем приложении для входа в систему пользователей учетной записи Google? Если да, вам следует также рассмотреть возможность входа в систему с учетной записью Microsoft, особенно если учесть, что вы хотите интегрироваться с экосистемой Microsoft. Как только это будет сделано, вы можете концептуально разрешить пользователю входить в систему с параметром -либо- (т. е. -обе-), сохраняя его уникальный идентификатор пользователя из каждой из этих систем в вашей базе данных. После этого вы можете обрабатывать вход пользователя в систему с помощью любой системы, например. Google в браузере или Microsoft в браузере или Teams.

Я думаю, что для маршрута Google вам необходимо выполнить проверку на серверной стороне, чтобы убедиться, что токен действителен. Для Microsoft это в основном то же самое, и поэтому вы можете выполнить проверку входа в систему через Teams практически таким же способом.

На самом деле я использую волшебную ссылку для входа, поэтому домен не имеет значения. Мне просто интересно, смогу ли я после запроса токена аутентификации и проверки этого токена создать ссылку для перенаправления их на него, если их адрес электронной почты существует в моей БД? Microsoft называет свой токен токеном аутентификации и токеном удостоверения, так безопасно ли это делать?