Google OAuth button not responding in iPad kiosk mode on iPad miniSolved

Hi @ame-lie,

This behavior usually points to how the authentication flow is handled inside the kiosk browser environment.

Hexnode Browser Lite and website kiosk modes that rely on an embedded WebView may not always handle external OAuth redirects the same way Safari does. Google sign-in, in particular, can fail inside restricted WebView containers because Google applies additional security checks for embedded authentication flows.

A useful way to isolate the cause is to compare the same web app outside kiosk mode:

1. Remove the kiosk policy temporarily.
2. Open the web app directly in Safari and test the Google sign-in flow.
3. Test the same URL in a WebView-based browser or WebView testing app.
4. Compare whether the issue occurs only in WebView-based rendering.

If Safari works but WebView does not, the issue is likely related to WebView compatibility rather than the kiosk policy assignment itself.

Best Regards,
Isabel Lora
Hexnode UEM

I tried this without the kiosk policy. The site works in Safari on the iPad mini and the Google login completes normally.

I also tested with a WebView tester app. “Open with Safari WebView” worked on both the iPad Air and iPad mini. But “Open with WebKit WebView” loaded the page and then did nothing when I tapped “Continue with Google”. Same result on both devices.

That matches what we have seen with Google OAuth in embedded WebViews. The button can appear normally, but the redirect or authentication handshake may be blocked or dropped by the WebView context.

In this case, the important finding is that the same Google login fails in a standard WebKit WebView test environment. That indicates this is not caused by a Hexnode policy misconfiguration or by one specific device record. It is a WebView compatibility limitation with the Google OAuth flow used by the web app.

Hexnode Browser Lite is WebView-based, so it can be affected by the same limitation. Safari works because it uses the full Safari browser context, which Google supports for authentication.

Best Regards,
Isabel Lora
Hexnode UEM

I also tried using Safari in the kiosk settings, but that does not really work for this setup. It blocks one of the required redirect pages, and the device ends up with the Safari tab/multi-page experience, which we do not want for the kiosk.

If Safari kiosk mode is not suitable, the practical alternatives are to avoid relying on Google OAuth inside an embedded WebView-based kiosk browser.

Possible approaches include:

• Use a version of the web app that does not require Google OAuth inside the kiosk WebView.
• Modify the application authentication flow to use a method supported in embedded or managed browser contexts.
• Package the site as a progressive web app, if the app and authentication flow support that deployment model.
• Use Safari-based access only if the required redirects and tab behavior are acceptable for the deployment.

For this specific behavior, there is no Hexnode kiosk policy toggle that forces Google OAuth to complete inside a WebKit WebView when the authentication provider blocks or restricts that context.

Best Regards,
Isabel Lora
Hexnode UEM