| Summary: | WebAuthn authentication includes security key as option when only "hybrid" is the potentially usable transport | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | matthew | ||||||
| Component: | WebKit Misc. | Assignee: | Nobody <webkit-unassigned> | ||||||
| Status: | NEW --- | ||||||||
| Severity: | Normal | CC: | abigail_fox, bfulgham, pascoe, webkit-bug-importer, wilander | ||||||
| Priority: | P2 | Keywords: | InRadar | ||||||
| Version: | Safari 16 | ||||||||
| Hardware: | Mac (Apple Silicon) | ||||||||
| OS: | macOS 13 | ||||||||
| Attachments: |
|
||||||||
Created attachment 465449 [details]
Showing the WebAuthn prompt with ["internal", "hybrid"] transports
Created attachment 465450 [details]
Showing the WebAuthn prompt with ["hybrid"] transports
|
## Context Safari's WebAuthn prompt behavior seems odd when credential transports are provided for a single entry in `allowCredentials`, and "hybrid" is the only potentially usable transport. For example, consider the case of a single passkey with ["internal", "hybrid"] for transports. The passkey is not recognized by the local platform authenticator over "internal" transport, so Safari asks the user to choose between the following two options: - iPhone, iPad, or Android device - Security key Why is "Security key" an option here, if the transports indicate that the passkey is only usable locally or from a mobile device's platform authenticator? It seems Safari should instead jump straight to the hybrid QR code display, because the RP hasn't communicated in any meaningful way that the user might be able to successfully use a security key. Additionally, in the somewhat contrite case of only ["hybrid"] for transports, Safari skips any choice and goes straight to the "Use Security key" prompt! This doesn't make any sense as "hybrid" isn't a security key-related transport. Here too Safari should display the hybrid QR code for authenticating with a mobile device. ## Environment - Safari 16.3 - macOS Ventura 13.2.1 ## Reproduction This basic HTML document demonstrates both scenarios listed above in a practical manner: ```html <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <style> body { max-width: 40em; } </style> <title>Safari Bug - Security key as option for ["internal", "hybrid"]</title> </head> <body> <h1> Safari Bug - Security key as option for ["internal", "hybrid"] </h1> <p> Demonstrating how Safari shows security keys as an option when the only allowed credential has ["internal", "hybrid"] as transports. Why would the browser think this is a security key? What if Safari simply skipped to the hybrid QR code when it doesn't recognize the credential as "internal"? </p> <button id="auth1">Authenticate w/['internal', 'hybrid']</button> <p> And to really emphasize how weird this is, Safari only shows security key as an option when only ["hybrid"] is set as transports for the sole entry in allowCredentials. Feels like Safari should skip to the hybrid QR code here too. </p> <button id="auth2">Authenticate w/['hybrid']</button> <script> // button#auth1 document.getElementById('auth1').addEventListener('click', () => { navigator.credentials.get({ publicKey: { challenge: new Uint8Array([1,2,3,4]), allowCredentials: [ { id: new Uint8Array([1]), type: 'public-key', transports: ['internal', 'hybrid'] }, ] }, }).then(console.log); }); // button#auth2 document.getElementById('auth2').addEventListener('click', () => { navigator.credentials.get({ publicKey: { challenge: new Uint8Array([1,2,3,4]), allowCredentials: [ { id: new Uint8Array([1]), type: 'public-key', transports: ['hybrid'] }, ] }, }).then(console.log); }); </script> </body> </html> ```