Issue
When a Pega Web Embed (Constellation) is accessed from mobile Safari on iOS, the authentication popup required to complete the OAuth 2.0 authorization code flow is silently blocked by the browser. The user sees only an unresponsive Login button with no error message and no path forward.
Symptoms and Impact
- The Web Embed page loads normally on mobile Safari.
- The user is presented with a button.
- Tapping the button produces no visible response — no popup appears, and no error is displayed.
- Authentication cannot complete. The user is effectively locked out of the embedded application.
This behavior occurs when pop-ups are disabled in the device's Safari settings (the iOS default). Safari does not notify the user that the popup was blocked.
External users who receive a Web Embed URL via email and open it on an iOS device cannot authenticate or access the application.
Steps to reproduce
- Configure a Pega Constellation application with a Web Embed channel using grantType="authCode" and an external identity provider (IdP).
- Send the Web Embed URL to an end user via email.
- Open the email on an iOS device.
- Tap the link to open the Web Embed page in mobile Safari.
- Tap the button.
- If pop-ups are allowed in Safari settings: the authentication popup opens and login completes normally.
- If pop-ups are blocked (iOS default): Safari silently suppresses the popup. The Login button appears unresponsive. No error message is shown. Authentication cannot proceed.
Root Cause
Pega Web Embed's authorization code opens a popup window to complete the OAuth redirect with the IdP. Modern mobile browsers — particularly mobile Safari on iOS — enforce aggressive popup-blocking policies. When a popup is blocked, Safari provides no browser-level notification to the user and no signal back to the hosting page. Pega Web Embed's default UI does not detect or surface this blocked-popup condition, leaving the user with no guidance.
This is a product limitation, not a configuration error.
Solution
There is no configuration change that eliminates the underlying limitation. An enhancement request has been submitted.
Users may wish to put in place a custom solution using the embedAuthFail event and authFailUI custom handler mechanisms exposed by the Web Embed script, but these would be custom code workarounds implemented and maintained by the application team hosting the Web Embed page.
User-facing guidance (device-level local change)
If a custom code change is not feasible, users can be instructed to allow pop-ups manually: → the website entry → →