Firefox does not support AsWebAuthenticationSession #589

marijngiesen commented 2026年03月02日 09:05:54 +01:00

There seems to be some new functionality that opens Safari when logging into EduVPN. This is super annoying when you don't use Safari as your browser. After logging in Safari keeps running and I have to quit it manually. Why is this changed? The previous versions allowed logging in using your default browser (which has my Bitwarden extension etc).

Please change this back to the way it used to work, or make it configurable.

There seems to be some new functionality that opens Safari when logging into EduVPN. This is super annoying when you don't use Safari as your browser. After logging in Safari keeps running and I have to quit it manually. Why is this changed? The previous versions allowed logging in using your default browser (which has my Bitwarden extension etc). Please change this back to the way it used to work, or make it configurable.

fkooman commented 2026年03月02日 11:43:56 +01:00

The reason why we changed this: #555

In macOS, the system opens the user’s default browser if it supports web authentication sessions, or Safari otherwise.

(Source: https://developer.apple.com/documentation/authenticationservices/aswebauthenticationsession)

It seems that Safari and Chrome support this, but e.g. Firefox does not. This came up in their issue tracker regarding another app as well: https://bugzilla.mozilla.org/show_bug.cgi?id=1921535

Which browser are you using? Can you find out their status regarding support for ASWebAuthenticationSession?

The reason why we changed this: https://codeberg.org/eduVPN/apple/issues/555 > In macOS, the system opens the user’s default browser if it supports web authentication sessions, or Safari otherwise. (Source: https://developer.apple.com/documentation/authenticationservices/aswebauthenticationsession) It seems that Safari and Chrome support this, but e.g. Firefox does not. This came up in their issue tracker regarding another app as well: https://bugzilla.mozilla.org/show_bug.cgi?id=1921535 Which browser are you using? Can you find out their status regarding support for `ASWebAuthenticationSession`?

marijngiesen commented 2026年03月02日 12:03:45 +01:00

Yeah, I'm using Firefox. So no AsWebAuthenticationSession yet.

Yeah, I'm using Firefox. So no `AsWebAuthenticationSession` yet.

fronbasal commented 2026年03月11日 02:06:28 +01:00

Seeing the same for Safari on the latest App Store release, unfortunately. Neither ungoogled chromium nor Safari managed to open an actual page, when closed they do open but won't navigate anywhere.

Seeing the same for Safari on the latest App Store release, unfortunately. Neither ungoogled chromium nor Safari managed to open an actual page, when closed they do open but won't navigate anywhere.

fkooman commented 2026年03月12日 00:58:22 +01:00

Which macOS are we talking about? I'm testing with macOS 15 and everything works exactly as expected: a new window just for the authentication/authorization is opened and gets focus.

It could be that "ungoogled chromium", like Firefox, doesn't support ASWebAuthenticationSession either?

Which macOS are we talking about? I'm testing with macOS 15 and everything works exactly as expected: a new window just for the authentication/authorization is opened and gets focus. It could be that "ungoogled chromium", like Firefox, doesn't support `ASWebAuthenticationSession` either?

fronbasal commented 2026年03月12日 01:02:22 +01:00

I‘m on the latest macOS 26.3.1 on an M1 Max platform, haven‘t just seen with with ungoogled chromium but also Safari, unfortunately. I‘ve tried to see if I get output in Console.app but couldn’t identify anything meaningful. Tried building the repo locally but am unfamiliar with Swift/XCode and especially their local code signing process, so avoided that for now. If it helps I can try to put some effort in and get it building locally to provide more meaningful debugging traces.

Unfortunately this is a breaking bug for me as a user as my institution doesn’t permit permanent OVPN configs issued by users.

Edit: also tested with latest Google Chrome, unfortunately same result.

I‘m on the latest macOS 26.3.1 on an M1 Max platform, haven‘t just seen with with ungoogled chromium but also Safari, unfortunately. I‘ve tried to see if I get output in Console.app but couldn’t identify anything meaningful. Tried building the repo locally but am unfamiliar with Swift/XCode and especially their local code signing process, so avoided that for now. If it helps I can try to put some effort in and get it building locally to provide more meaningful debugging traces. Unfortunately this is a breaking bug for me as a user as my institution doesn’t permit permanent OVPN configs issued by users. Edit: also tested with latest Google Chrome, unfortunately same result.

fkooman commented 2026年03月12日 08:41:05 +01:00

Tested with Chrome on macOS 15 (Chrome set as default browser), works exactly as expected. Upgrading my MBP to macOS 26 now.

Tested with Chrome on macOS 15 (Chrome set as default browser), works exactly as expected. Upgrading my MBP to macOS 26 now.

fkooman commented 2026年03月12日 09:26:27 +01:00

I just tested on macOS 26.3.1 with eduVPN 4.0.7 (2309) with both Safari as default browser and Chrome as default browser, and everything works fine.

The only issue I found is that if you have Chrome as default browser it will also open a normal Chrome browsing session behind the authentication/authorization window and leave it open after the authentication/authorization is finished and the dedicated window for that is automatically closed.

Support for ASWebAuthenticationSession in other browsers, like "Ungoogled Chromium" is a bit tricky, as they'll have to implement support for that, just like Firefox needs to do.

I just tested on macOS 26.3.1 with eduVPN 4.0.7 (2309) with both Safari as default browser and Chrome as default browser, and everything works fine. The only issue I found is that if you have Chrome as default browser it will *also* open a normal Chrome browsing session _behind_ the authentication/authorization window and leave it open after the authentication/authorization is finished and the dedicated window for that is automatically closed. Support for `ASWebAuthenticationSession` in other browsers, like "Ungoogled Chromium" is a bit tricky, as they'll have to implement support for that, just like Firefox needs to do.

fkooman commented 2026年03月12日 09:30:34 +01:00

After logging in Safari keeps running and I have to quit it manually.

This I also see. It doesn't (really) close it... Not sure this is something we can fix, it might be up to Apple to do that.

> After logging in Safari keeps running and I have to quit it manually. This I also see. It doesn't (really) close it... Not sure this is something we can fix, it might be up to Apple to do that.

fronbasal commented 2026年03月12日 16:39:32 +01:00

Well I'm on Version 4.0.7 (2309), macOS 26.3.1 (25D2128) and couldn't get it working with any mainline browser 😅

While I do get the "eduVPN.app" Wants to Use "uni-due.de" to Sign In" prompt (and the browser (e.g. Chrome, Safari)) opens, I neither get a seperate expected auth window nor a new tab.

Edit: I found the fix in this chromium bug report.

The workaround is killing the SafariLaunchAgents, afterwards the session initiates as expected.

Well I'm on Version 4.0.7 (2309), macOS 26.3.1 (25D2128) and couldn't get it working with any mainline browser 😅 While I do get the `"eduVPN.app" Wants to Use "uni-due.de" to Sign In"` prompt (and the browser (e.g. Chrome, Safari)) opens, I neither get a seperate expected auth window nor a new tab. Edit: I found the fix in [this chromium bug report](https://issues.chromium.org/issues/40840827). The workaround is killing the SafariLaunchAgents, afterwards the session initiates as expected.

wood commented 2026年03月21日 09:27:21 +01:00

I have the same issue in macOD 26.3.1. Safari, brave and chrome do not work. The Authorization webpage does not open.

I have the same issue in macOD 26.3.1. Safari, brave and chrome do not work. The Authorization webpage does not open.

roopc commented 2026年03月21日 12:30:21 +01:00

@wood When you first tried to authenticate on the 4.0.7 release, what was your default browser set to?

The workaround seems to be to kill the SafariLaunchAgent process, and try again. Do you think you can try that?

@wood When you first tried to authenticate on the 4.0.7 release, what was your default browser set to? The workaround seems to be to kill the SafariLaunchAgent process, and try again. Do you think you can try that?

b-pfl commented 2026年04月27日 12:30:41 +02:00

Same issue happens on MacOS 14.8.5 with Firefox >= 149.x as default browser. Why at all was there any behavior change? I do not want to use Safari for authentication.

Same issue happens on MacOS 14.8.5 with Firefox >= 149.x as default browser. Why at all was there any behavior change? I do not want to use Safari for authentication.

pauldekkers commented 2026年05月12日 15:59:00 +02:00

FWIW; this new feature completely breaks x509 authentication on macOS, unless you install Brave/Chrome as default browser. A normal Safari browser would use a client-certificate, this new browser doesn't. So it is broken when the browser is Safari, or Firefox. I would love to see the old behaviour back.

FWIW; this new feature completely breaks x509 authentication on macOS, unless you install Brave/Chrome as default browser. A normal Safari browser would use a client-certificate, this new browser doesn't. So it is broken when the browser is Safari, or Firefox. I would love to see the old behaviour back.

fkooman commented 2026年05月12日 17:37:07 +02:00

It is not a new browser, it is "just" Safari without address bar. Why Apple decided that X.509 client certificate authentication shouldn't work when using Safari with ASWebAuthenticationSession is unclear to me. Maybe intentional, maybe a bug, who knows. Did you report this to Apple? Is there even a channel to report such things?

At this point I'm unsure how to proceed. There seem to be too many bugs everywhere, even with the browsers that implement ASWebAuthenticationSession 🤷

@roopc Any thoughts? How sure are we that Apple will still allow an app update without ASWebAuthenticationSession? Is it an option to use ASWebAuthenticationSession for the App Store version, and "Loopback" for the out-of-store version?

It is not a new browser, it is "just" Safari without address bar. Why Apple decided that X.509 client certificate authentication shouldn't work when using Safari with `ASWebAuthenticationSession` is unclear to me. Maybe intentional, maybe a bug, who knows. Did you report this to Apple? Is there even a channel to report such things? At this point I'm unsure how to proceed. There seem to be too many bugs everywhere, even with the browsers that implement `ASWebAuthenticationSession` 🤷 @roopc Any thoughts? How sure are we that Apple will still allow an app update without `ASWebAuthenticationSession`? Is it an option to use `ASWebAuthenticationSession` for the App Store version, and "Loopback" for the out-of-store version?

roopc commented 2026年05月13日 15:30:57 +02:00

It sounds weird that client certification auth doesn't work only with ASWebAuthenticationSession but otherwise works with Safari. I assume that the certificate is installed in the keychain, so it should work in both cases the same way. Let's test this and make sure this is indeed the case.

If we do find that this is the case, that's probably big enough for us to ditch ASWebAuthenticationSession. Then let's file an issue with Apple and submit an update with localhost-server-based auth -- if app review asks us, we'll point to the issue we filed with Apple as the reason we removed ASWebAuthenticationSession usage.

What do you think of this plan?

Is it an option to use ASWebAuthenticationSession for the App Store version, and "Loopback" for the out-of-store version?

Yes, that's an option. It makes the code a little complicated though. We can consider this if the above plan doesn't work.

It sounds weird that client certification auth doesn't work only with ASWebAuthenticationSession but otherwise works with Safari. I assume that the certificate is installed in the keychain, so it should work in both cases the same way. Let's test this and make sure this is indeed the case. If we do find that this is the case, that's probably big enough for us to ditch ASWebAuthenticationSession. Then let's file an issue with Apple and submit an update with localhost-server-based auth -- if app review asks us, we'll point to the issue we filed with Apple as the reason we removed ASWebAuthenticationSession usage. What do you think of this plan? > Is it an option to use ASWebAuthenticationSession for the App Store version, and "Loopback" for the out-of-store version? Yes, that's an option. It makes the code a little complicated though. We can consider this if the above plan doesn't work.

fkooman commented 2026年05月13日 18:34:49 +02:00

It sounds weird that client certification auth doesn't work only with ASWebAuthenticationSession but otherwise works with Safari. I assume that the certificate is installed in the keychain, so it should work in both cases the same way. Let's test this and make sure this is indeed the case.

I just tested it, it is a bit tricky to set up and use... I imported a P12 in the "System" chain or however that is called (importing it in the "Local"/"User" chain didn't work, it gave an error without any details.

When using Safari it keeps asking for username and password (?) a bunch of times to "unlock" the client certificate, but it does work with ASWebAuthenticationSession as well. I don't know why it is so idiotic that it keeps asking for a username and password, without even prefilling the username.

image

I'm using the latest macOS 26.5 with Safari set as default browser.

> It sounds weird that client certification auth doesn't work only with ASWebAuthenticationSession but otherwise works with Safari. I assume that the certificate is installed in the keychain, so it should work in both cases the same way. Let's test this and make sure this is indeed the case. I just tested it, it is a bit tricky to set up and use... I imported a P12 in the "System" chain or however that is called (importing it in the "Local"/"User" chain didn't work, it gave an error without any details. When using Safari it keeps asking for username and password (?) a bunch of times to "unlock" the client certificate, but it *does* work with `ASWebAuthenticationSession` as well. I don't know why it is so idiotic that it keeps asking for a username and password, without even prefilling the username.  I'm using the latest macOS 26.5 with Safari set as default browser.

b-pfl commented 2026年05月18日 18:54:35 +02:00

@fkooman wrote in #589 (comment):

It is not a new browser, it is "just" Safari without address bar. Why Apple decided that X.509 client certificate authentication shouldn't work when using Safari with ASWebAuthenticationSession is unclear to me. Maybe intentional, maybe a bug, who knows. Did you report this to Apple? Is there even a channel to report such things?

At this point I'm unsure how to proceed. There seem to be too many bugs everywhere, even with the browsers that implement ASWebAuthenticationSession 🤷

@roopc Any thoughts? How sure are we that Apple will still allow an app update without ASWebAuthenticationSession? Is it an option to use ASWebAuthenticationSession for the App Store version, and "Loopback" for the out-of-store version?

I suggest trying an update without ASWebAuthenticationSession through the App Store. If they reject, I propose to claim a file according to EU DSA that they misuse their position as a gatekeeper and put their own Browser in an advantageous situation.

@fkooman wrote in https://codeberg.org/eduVPN/apple/issues/589#issuecomment-14735517: > It is not a new browser, it is "just" Safari without address bar. Why Apple decided that X.509 client certificate authentication shouldn't work when using Safari with `ASWebAuthenticationSession` is unclear to me. Maybe intentional, maybe a bug, who knows. Did you report this to Apple? Is there even a channel to report such things? > > At this point I'm unsure how to proceed. There seem to be too many bugs everywhere, even with the browsers that implement `ASWebAuthenticationSession` :shrug: > > @roopc Any thoughts? How sure are we that Apple will still allow an app update without `ASWebAuthenticationSession`? Is it an option to use `ASWebAuthenticationSession` for the App Store version, and "Loopback" for the out-of-store version? I suggest trying an update without ASWebAuthenticationSession through the App Store. If they reject, I propose to claim a file according to EU DSA that they misuse their position as a gatekeeper and put their own Browser in an advantageous situation.