Page MenuHomePhabricator

On iPhone, after cancelling WebAuthn authentication process, cannot restart it again
Open, Needs TriagePublicBUG REPORT

Description

What is the problem?

On iPhone, when asked to authenticate with a WebAuthn device, if it times out or you cancel, you cannot then authenticate with a WebAuthn device anymore, not even after logging in (with a different 2FA method), trying to login as a different user with WebAuthn or clearing cookies.

I have reproduced this on Safari on iPhone 14 but not on iPhone 15.

Found by @AAlhazwani-WMF.

Steps to reproduce problem
  1. Login to beta
  2. Go to https://auth.wikimedia.beta.wmcloud.org/enwiki/w/index.php?title=Special:AccountSecurity
  3. Click "Add security key" and add your security key (e.g. a yubikey)
  4. On an iPhone, attempt to login on beta with the same user
  5. After entering your username and password, you will be prompted to enter a security key. Instead, cancel by closing the popup
  6. Reload the page and try to login again (you might be asked for your username and password again)

Expected behaviour: You get the prompt to enter your security key again.
Observed behaviour: It immediately shows you a failure ("Authentication process was interrupted...")

Environment

Operating system: iPhone 14 iOS 16.3.
Browser: Safari.
Wiki(s): https://en.wikipedia.beta.wmflabs.org OATHAuth – (a0b34f0) 07:34, 6 October 2025. WebAuthn – (1957699) 20:10, 3 October 2025.

Screenshots

Event Timeline

OATHAuth's login.js auto-fires navigator.credentials.get() on page load
Apple had strict user gesture gating on actions like this in previous iOS versions.

Initially, all these actions had to be behind a user gesture. https://webkit.org/blog/11312/meet-face-id-and-touch-id-for-the-web/
In iOS 15 through 17.3 the user got a single 'free' request. And then from 17.4, the whole mechanism was replaced with a rate limit of sorts.

The iPhone with the problem was running 16.3. The other iPhone was newer and is more likely to run 17.4 or higher. I suspect that the problem dom identified is caused by this consuming of the free request outside of a user gesture is being consumed by the page load. I guess this is being preserved over page reloads ?

This might tie into T404773: Don't force reload to retry after WebAuthn failure