Closed Bug 1973897 Opened 1 year ago Closed 10 months ago

BankID.com official identification method doesn't work

Categories

(Web Compatibility :: Site Reports, defect, P2)

Unspecified
Android

Tracking

(Webcompat Priority:P2, Webcompat Score:6)

RESOLVED WORKSFORME
Webcompat Priority P2
Webcompat Score 6

People

(Reporter: pehrsons, Unassigned)

References

()

Details

(Keywords: webcompat:needs-diagnosis, webcompat:site-report)

User Story

platform:android
impact:workflow-broken
configuration:general
affects:all
branch:release
diagnosis-team:android
user-impact-score:400

BankID is a Swedish electronic identification system owned by all major Swedish banks. It is the biggest form of electronic ID in Sweden and used for identification and signing on all kinds of sites from shopping, payments, banking and government services.

My starting conditions:

  • Fenix release
  • Open links in apps: prompt
  • BankID native app installed, and I have a certificate.

The official way to identify yourself with a BankID that is installed on the same device as your browser is documented on developers.bankid.com's autostart page. Note under Launching from a browser and Mobile the

Please note: The URL works only on Chrome on Android and Safari on iOS.

BankID has a demo page on which one can test their signature flow, including with a test certificate: https://developers.bankid.com/test-portal/testing/sign-test. Click the "Open BankID on this device" and notice how it's different in Chrome and Firefox. In Chrome, the app launches immediately. In Firefox a prompt is shown asking whether to open the app, and the URL is loaded in the background -- as it appears it is intended to show the user information on how they can fix their configuration when the app doesn't open at all. Generally, after opening the app through the prompt in Firefox (with a real id installed), the identification flow in the app succeeds, but on returning to the browser you're stuck on the still-loaded bankid.com url.

Note for testing a production BankID one can use https://test.bankid.com, which exhibits the same problem.
I originally faced this problem on https://www.hygglo.se, trying to log in.

As a counter example, the Swedish tax authority on https://skatteverket.se, provides the means to login in Firefox with the same-device BankID native app. Then there is no bankid.com URL loading in the background while being shown the prompt on whether to open the URL in an app.

Note trying to log in on https://skatteverket.se does

document.location = handleScheme(handleReturnUrl('bankid:///?autostarttoken=<sometoken>&redirect=null'));

resolving to

document.location = "bankid:///?autostarttoken=<sometoken>&redirect=null";

TL;DR
The official method, which doesn't work in Firefox on Android, essentially says to do

document.location = "https://app.bankid.com/?autostarttoken=<sometoken>&redirect=null";

Sweden's second largest digital ID provider, Freja eID seems to suffer from the same problem, and here it's baked into their oidc-login client script. Here the relevant bit unminified:

function frejaeidOidcLogin(e, r, t, o, l) {
  (url = "https://oidc.prod.frejaeid.com/oidc/authorize"),
    "Test" == l && (url = "https://oidc-ct.test.frejaeid.com/oidc/authorize"),
    e.startsWith("http") || (window.location.href = encodeURI(url + "?client_id=" + e + "&redirect_uri=" + r + "&scope=" + t + "&response_mode=" + o + "&response_type=code"));
}

Note that with the setting to always open links in apps, I am able to log in.

The severity field is not set for this bug.
:twisniewski, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(twisniewski)
See Also: → 1976200

Ideally, we'd also have one site report for each site that is using this authentication method, but that's probably a long list :/

Severity: -- → S2
User Story: (updated)
Webcompat Priority: --- → P2
Webcompat Score: --- → 6
Component: Report Broken Site → Site Reports
Flags: needinfo?(twisniewski)
Priority: -- → P2
Product: Firefox → Web Compatibility

For the record, a site patch here isn't really feasible. It's impossible for JS redefine window.location (for hopefully obvious reasons) to detect the attempt and try to do something else. Similarly, rewriting their scripts to do something else would likely be very tricky to get right, and be fragile. That's even assuming we can do something else. I think the only real solution here would be for us to detect attempts to redirect to specific URLs and open them in an app (which would hopefully be straightforward for bankid: URLs, at least).

User Story: (updated)
Webcompat Score: 6 → 1
User Story: (updated)
Webcompat Score: 1 → 6
See Also: → 1993517

Given that this is on Android and related to native-app-launch for URIs that (presumably) a native-app is registered to handle, royang is likely a good point-of-contact here. CC'ing him.

I know we've landed several fixes related to external-app-launch over the past few months, too (e.g. bug 1980753, though that one's probably not relevant here), so it might be worth re-testing to see if this still reproduces in latest Nightly. Andreas, would you mind re-testing?

Assuming this is still reproducible: if it's possible to come up with a reduced testcase and platform-bug (in Firefox for Android | App Links component) with some sort of brief diagnosis -- e.g. navigating-via-assignment-to-document.location failing to launch external apps, if that's accurate (seems like it might be, per comment 1 and comment 2?) -- then we should probably mark that platform-bug as blocking bug 1994799.

Flags: needinfo?(apehrson)

I have re-tested the sites in question and could successfully auth on BankID's test sites, hygglo.se and skatteverket.se. Both on 144 release and 146 Nightly (Oct 20).

I am hitting an issue when veering off the happy-path though: after getting prompted to open the app and cancelling that prompt, I am not able to get the external app to open again, nor do I get prompted. Instead Firefox loads the app link. Even changing the setting to always open in app doesn't bring it back. With the whole prompt-fatigue from cookie banners, this happens fairly regularly. Killing Firefox and restarting works, but is not very discoverable for the regular user. I'll file an issue for that and am closing this bug as WFM as I don't know what fixed it.

Status: NEW → RESOLVED
Closed: 10 months ago
Flags: needinfo?(apehrson)
Resolution: --- → WORKSFORME
See Also: → 1847273
You need to log in before you can comment on or make changes to this bug.