apache / cordova-plugin-inappbrowser

Apache Cordova InAppBrowser Plugin
https://cordova.apache.org/
Apache License 2.0
1.11k stars 2.14k forks source link

@awesome-cordova-plugins/in-app-browser, this plugin is not sending the device id to azure while login + iOS #1049

Closed RonCocoa closed 2 months ago

RonCocoa commented 2 months ago

Bug Report

@awesome-cordova-plugins/in-app-browser, this plugin is not sending the device id to azure while login

Problem

We are using next-auth.js lib for login in mobile application with capacitor plugin. And open login page within a iOS app, using the @awesome-cordova-plugins/in-app-browser. We are using Azure AD provider for login with next auth js. and the In app browser does not send the device id to the Azure Active Directory. Due to that we are unable to find out the device compliances.

What is expected to happen?

It should send the device id.

OS: iOS/iPad OS Version : 17 onward

breautek commented 2 months ago

Moved this to the inappbrowser repo since the issue is asking about this plugin, @awesome-cordova-plugins/in-app-browser, appears to be just a typescript def into this plugin.

We are using Azure AD provider for login with next auth js. and the In app browser does not send the device id to the Azure Active Directory. Due to that we are unable to find out the device compliances.

The in-app browser's responsibility is to open up a remote/third-party web page. So I'm a bit confused on what you mean by the device id and why the in-app-browser should "send" it. System level device ids on modern devices are also blocked and not readable without special privileges which only system apps would have.

If the device id is something you generate and manage yourself (via your own code, or through azure AD) then it would the app's responsibility to propagate that id, in which case you should have code doing so. Can you provide some sample code on that you expect to work?

RonCocoa commented 2 months ago

@breautek, When we use the Capacitor's browser instead of the InAppBrowser for the authentication library, we observe that the compliance status of the device is obtained. However, when using the InAppBrowser, we do not receive this compliance status.

breautek commented 2 months ago

I think that's because capacitor's browser uses SFSafariViewController behind the scenes.

Which is similar to an embedded webview but with far more restrictions. These restrictions however makes it safer for OAuth usage. The inappbrowser plugin uses WKWebView for legacy reasons, it's configured in such a way that it doesn't have access to the cordova bridge making it safe to load in untrusted content, but it has APIs for the host app to inject content into the loaded document, breaching trust for OAuth service providers, which I suspect is related to your compliance status. Many OAuth providers started blocking OAuth usage from embeddable webviews like WKWebView and android's Webkit webview.

There are no plans to implement Safari View Controller in this plugin because it would destroy a lot of features that other users rely on, but there is a community plugin available cordova-plugin-safariviewcontroller that does implement the Safari View Controller. Despite the name, it also supports Chrome Tabs for android, which is android's direct equivalent feature to iOS's Safari View Controller. I've haven't used this plugin myself, but it sounds like the exact thing you need if Capacitor's module doesn't work on Cordova.