We have a working implementation of a redirect Extensible Single Sign-On (ESSO) extension (MDM delivered SSO profile, Authentication Service Extension, Associated domains, etc).
One of the selling points of this feature for us is the Bundle ID and Management Status sent as input to the ESSO extension
through the ASAuthorizationProviderExtensionAuthorizationRequest. We rely on iOS to securely and reliably provide the Bundle ID of the calling app as a security factor on our authentication process. However, while testing we encountered Apps that internally use SafariViewService to display web content. When SafariViewService is used by a calling App in the ESSO flow, the information passed to the ESSO extension is the data of SafariViewService. This behavior removes the secure and reliable way of getting the calling App’s data from iOS.
How can we have access to the calling App data (Bundle ID, Management Status) when the calling App is using SafariViewService ?
One of the selling points of this feature for us is the Bundle ID and Management Status sent as input to the ESSO extension
through the ASAuthorizationProviderExtensionAuthorizationRequest. We rely on iOS to securely and reliably provide the Bundle ID of the calling app as a security factor on our authentication process. However, while testing we encountered Apps that internally use SafariViewService to display web content. When SafariViewService is used by a calling App in the ESSO flow, the information passed to the ESSO extension is the data of SafariViewService. This behavior removes the secure and reliable way of getting the calling App’s data from iOS.
How can we have access to the calling App data (Bundle ID, Management Status) when the calling App is using SafariViewService ?