How to bring webauth session to front

Question

Created 4h

Replies 1

Boosts 0

Participants 2

We have an application (macOS) which opens an ASWebAuthenticationSession window to prompt the user for credentials. This works well, except for there are times when the window is opened behind other windows - and the user does not see that they are being prompted for authentication.

Is there some way to force this window to be always-on-top or at the very least, to bring it to the foreground on top of other windows (including other browser windows from the same default system browser).

Answered by DTS Engineer in 898672022

Thanks for the clear description. I reproduced this on macOS, and the cause is that the authentication page is shown in the default browser. That window belongs to the browser rather than to your app, which is why you are seeing this behavior.

The documentation states the macOS behavior directly:

"In iOS, the browser is a secure, embedded web view. In macOS, the system opens the user's default browser if it supports web authentication sessions, or Safari otherwise."

In my test the page opened as a Safari window, and starting the session brought Safari and all of its windows forward. That matches what you describe: the authentication page is one of the browser's windows, so it can end up behind the browser's other windows.

Because that window belongs to the browser, which is a separate application, the app cannot set it always-on-top or move it above the browser's other windows. ASWebAuthenticationSession does not expose a window level or an ordering control. Its only presentation inputs are the presentation anchor and prefersEphemeralWebBrowserSession. The anchor is an NSWindow used as context for where the request originates, and prefersEphemeralWebBrowserSession affects cookie sharing rather than window placement. One application cannot reorder another application's windows, so there is no reliable way to force the authentication window forward from your side.

Surfacing the authentication window reliably above the browser's other windows is behavior only the browser and the system control. If that matters for your flow, a request through Feedback Assistant is the way to ask for it. Describing your use case, the window getting lost behind the browser's other windows, would help.

There is one alternative with real trade-offs, if you need to own the window: present the authentication page yourself in a WKWebView inside a window your app controls. That gives you full control over window level and ordering. In exchange, it gives up what ASWebAuthenticationSession provides: the system-integrated sign-in and shared web session, the isolation between your app and the credentials, and the guarantee that only your app receives the callback. Many identity providers also block sign-in from embedded web views. So it is a genuine trade-off to weigh, not a drop-in improvement.

For reference:

Answer 1

DTS Engineer OP

Apple

2m

Recommended

Thanks for the clear description. I reproduced this on macOS, and the cause is that the authentication page is shown in the default browser. That window belongs to the browser rather than to your app, which is why you are seeing this behavior.

The documentation states the macOS behavior directly:

"In iOS, the browser is a secure, embedded web view. In macOS, the system opens the user's default browser if it supports web authentication sessions, or Safari otherwise."

In my test the page opened as a Safari window, and starting the session brought Safari and all of its windows forward. That matches what you describe: the authentication page is one of the browser's windows, so it can end up behind the browser's other windows.

Because that window belongs to the browser, which is a separate application, the app cannot set it always-on-top or move it above the browser's other windows. ASWebAuthenticationSession does not expose a window level or an ordering control. Its only presentation inputs are the presentation anchor and prefersEphemeralWebBrowserSession. The anchor is an NSWindow used as context for where the request originates, and prefersEphemeralWebBrowserSession affects cookie sharing rather than window placement. One application cannot reorder another application's windows, so there is no reliable way to force the authentication window forward from your side.

Surfacing the authentication window reliably above the browser's other windows is behavior only the browser and the system control. If that matters for your flow, a request through Feedback Assistant is the way to ask for it. Describing your use case, the window getting lost behind the browser's other windows, would help.

There is one alternative with real trade-offs, if you need to own the window: present the authentication page yourself in a WKWebView inside a window your app controls. That gives you full control over window level and ordering. In exchange, it gives up what ASWebAuthenticationSession provides: the system-integrated sign-in and shared web session, the isolation between your app and the credentials, and the guarantee that only your app receives the callback. Many identity providers also block sign-in from embedded web views. So it is a genuine trade-off to weigh, not a drop-in improvement.

For reference: