Passkeys iOS 18: Automatic Passkey Creation & Upgrades

Apple continues to extend the feature set of its operating systems and browsers for passkeys. In iOS 18, iPadOS 18, and macOS 15, additional WebAuthn functionalities will be supported. In this article, we will explore:

• What new passkey-related functionalities are part of iOS 18, iPadOS 18, and macOS 15?
• What is Apple's strategy regarding passkeys?

Let's start by examining the functionalities that have been announced during WWDC 2024 and part of iOS18.

Apple has introduced a new password manager app, called Passwords, as part of the iOS 18, iPadOS 18 und macOS 15 operating systems. Let’s take a look why this is important for automatic passkey upgrades.

You can test the automatic passkey upgrade in this demo.

The introduction of a stand-alone password app shows how crucial passwords, passkeys and secret management is in the eyes of Apple. Apple thereby created an app on the same level as established password managers (e.g. 1Password or Dashlane), “sherlocking” these products. At the same time, Safari 18 supports automatic passkey upgrades.

The upgrades build on the WebAuthn Conditional Registration Extension (see also our other blog post). This extension allows relying parties to register a passkey automatically during password autofill login facilitating a smooth transition from passwords to passkeys.

The important part is that this passkey upgrade happens automatically after a password autofill by the new Passwords app on iOS 18. As autofill triggers a Face ID or Touch ID scan in the same process, the creation of a credential with the iOS 18 authenticator will be allowed. The browser knows that it just mediated a password manager autofill and only then will allow the automatic passkey creation. In other cases (e.g. entering password manually), the conditional mediation will not work, because there is no prior authentication that can count as consent to a passkey creation

If you already have the iOS 18 installed, you can test passkey upgrades with the demo that Nov Matake has created (source code available here). The details and source code examples from Apple can be found here.

We have created some screenshots for you in case you have not installed iOS18 yet:

In the first picture, we start by creating a password-based account and store the password in the new Passwords app by Apple (see the notification at the top of the screenshot).

In the second screen, we log in using the password autofill of the Passwords app. The example app supports Conditional Mediation for passkey creation and therefore a passkey is automatically created, because the security is upgraded with a non-phishable passkey.

Apple has named it “upsell” or passkey upgrade (see the notification on top of the third screenshot).

Subscribe to our Passkeys Substack for the latest news, insights and strategies.

Subscribe

Information regarding the technical background of passkey upgrades can be found in the current W3C Editor’s Draft. The explainer and the resulting issue for the WebAuthn standard were mainly driven by Apple. But let’s take a look at the actual implementation.

Detect support within browser

// Check if PublicKeyCredential is supported in the current browser
 
if (typeof PublicKeyCredential === 'undefined') {
    console.log("PublicKeyCredential is not supported in this browser.");
    return;
}
 
// Check if getClientCapabilities method exists on PublicKeyCredential
 
if (typeof PublicKeyCredential.getClientCapabilities === 'function') {
    try {
        let capabilities = await PublicKeyCredential.getClientCapabilities();
        if (!capabilities.conditionalCreate) {
            console.log("Conditional create is not supported. Do not continue with mediation.");
            return; // Do not continue with mediation
        }
        console.log("Conditional create is supported. Continue with mediation.");
        // Continue with mediation
    } catch (error) {
        console.error('Error getting client capabilities:', error);
        // Handle the error appropriately
    }
} else {
    console.log('getClientCapabilities is not supported in this browser');
    // Handle the case where the method is not supported
}

At first, we need to detect if the passkey upgrade functionality can be used in current browser. At the moment, the only browser that will support it is Safari 18, but more browsers are expected to follow soon. As you can see, the getClientCapabilities() call is used to determine the functionality. This is a new function that has been implemented to reflect all future functionality that might be part of WebAuthn. Safari has supported it since version 17.4.

Part of the result are all information that are helpful from a RP perspective. Keep in mind that this function is not yet implemented in all browsers. Most of the information is currently available via other interfaces, for example: userVerifyingPlatformAuthenticator is available via isUserVerifyingPlatformAuthenticatorAvailable() call.

After detecting support for conditionalCreate, we can use Conditional Mediation in the navigator.credentials.create call:

Implementation of conditional registration:

const options = {
 
    "publicKey": {
        "rp": {
            …
        },
        "user": {
 
            "name": userInfo.user,
            …
        },
        "challenge": …,
        "pubKeyCredParams": […]
    },
    "mediation": "conditional"
};
 
await navigator.credentials.create(options);

As you can see above, the implementation is very similar to Conditional UI. By adding ”mediation”: “conditional” to the PublicKeyCredentialCreationOptions, the process will be triggered by Safari after a password autofill and a passkey will be created.

Resulting passkeys

Passkeys created via the Conditional Create Mediation do not carry the UP or UV flag (see JSON above) because the identification was not part of the actual WebAuthn ceremony. That means that those flags need to be monitored on further authentication ceremonies and the implementation needs to take care that those flags are represented correctly in future ceremonies. During our tests, the UP and UV flag were both set to true, when the automatically created passkey was used for authentication.

Become part of our Passkeys Community for updates and support.

Join

The PRF extension allows websites to leverage WebAuthn for more than just authentication by enabling the handling of cryptographic functions. PRF stands for pseudo-random function, which is an important requirement in cryptography. This extension is particularly beneficial for sites implementing end-to-end encryption. PRF outputs can be used by websites for symmetric encryption of user data. Decrypting data only works after a successful WebAuthn authentication ceremony which is used also used to re-create the same symmetric encryption key by providing the same initial seed byte codes to the PRF. The symmetric encryption is bound to the actual credential. In case the credential is lost, the derived symmetric key is lost as well.

By integrating the CTAP2 hmac-secret extension, which many security keys already support, this feature provides a robust mechanism for generating per-credential secret keys (help creating symmetric keys from the actual asymmetric public-private credential). This enhances security by ensuring that key material is both secure and easily accessible during authentication, thereby benefiting users and service providers looking to strengthen their cryptographic operations. Historically, this feature was mainly used with hardware security keys (e.g. YubiKeys) but it is now also usable with platform authenticators (e.g. Face ID, Touch ID, Windows Hello).

Possible use cases for the PRF extension:

• Encrypted communication: User communication can be encrypted, ensuring the confidentiality and integrity of the transmitted data. The symmetric secret, derived via the PRF extension, becomes a crucial part of the encryption algorithms, making the content inaccessible even to the service provider.
• Secure vaults (e.g. password manager): When a user registers a passkey, a password could leverage the PRF extension to generate an encryption key. This key is used to encrypt the user’s vault data, ensuring a high level of security in addition to strong authentication. This, of course, works also for passkeys on hardware security keys (as Bitwarden has already outlined).
• Many more use cases: Basically, any web application that currently uses some kind of user data encryption can now level up and use passkeys for authentication and use the same passkey to extract the symmetric encryption key. This could also be used as a kind of second recovery mechanism, in case the user forgets a master passphrase.

Two articles that dive deeper into the technical background including examples and online test are here and here.

WebKit will support passkeys on more than one origin. By default, WebAuthn credentials are linked to a single Relying Party ID (RP ID), typically a domain name, which confines their use to specific origins. This restriction ensures credentials are not universally applicable, making them phishing-resistant. However, challenges arise for sites with multiple country-specific domains, brands spanning multiple domains, or mobile apps without distinct domains.

To address these issues, the WebAuthn proposal suggests using a well-known URL, where an origin can list other authorized origins. Let’s have a look at an example: imagine a website acts as a relying party (RP) on the domain example.com and wants the passkeys to also work on example.co.uk and example2.com. The .well-known/webauthn JSON file:

• Should be uploaded to:
  https://example.com/.well-known/webauthn

• Should have the following content structure:

  {
      "origins": [
          "https://example.com",
          "https://example.co.uk",
          "https://example2.com"
      ]
  }
  

This allows already created credentials to be used across different but related domains of the RP example.com, facilitating a more seamless user experience without compromising security. This method aims to simplify WebAuthn deployment across various platforms and reduce barriers to adoption while maintaining stringent security protocols.

This is especially important for RPs that work on different international domains (e.g. kayak.com + kayak.de) or have affiliated websites within the same company. Establishing trust via ./ well-known files has proven to be an easy and secure method for native apps – this concept is now also leveraged for passkeys. The details of the initial standard draft can be found here. The final implementation details will be available after the official release of Safari 18.

Important: While most of the new WebAuthn additions can be used in browsers as soon as they are implemented, rolling out this function to consumers is not recommended yet due to the lack of full browser support. Leveraging this functionality before all major browsers support it could result in users being unable to log in.

Apple's passkey strategy emphasizes the importance of seamless and secure user experiences across their ecosystem, which spans various devices and operating systems. As part of their commitment to enhancing security, Apple is focusing on making it easier for users to manage their credentials and transition smoothly between devices without compromising their data.

Recognizing the challenges consumers face with data security on different websites, Apple continues to support the WebAuthn standard implementing new functionality even before it is officially part of the next WebAuthn standard release.

It is remarkable that the actual “connection” of a user to a web service / relying party will shift significantly in the future. Today the connection is established by a password that the user provides. Tomorrow, the connection will be via the personal cloud account of the user, as passwords will be replaced by an everlasting secure passkey connection from the user’s operating system cloud (e.g. Apple iCloud, Google account and soon Microsoft account). As passkeys are rarely deleted manually and cannot be forgotten (in contrast to passwords), relying parties can win their customers forever.

We believe, in the future, automatic authentication with passkeys will be the standard. Offering passkey as “customer connection”, allowing for cross-device authentication and managing passkeys of different operating system clouds will be at the heart of every consumer-facing business.

To sum up, the latest updates in iOS 18, iPadOS 18, and macOS 15 introduced at WWDC2024 include:

• New Passkey Features: The integration of a new password manager app and automatic passkey upgrades using the WebAuthn Conditional Registration Extension. The new passkey features also include support for the PRF extension for cryptographic operations and the ability to use passkeys across related but different domains.
• Apple's Passkey Strategy: Apple aims to improve security and user experience across devices by managing and transitioning credentials seamlessly as part of the operating system. This is a major strategic move, and it is very likely Microsoft and Google will follow soon.

To keep up with the passkeys developments, it is crucial that developers keep track of the changelogs of Firefox, WebKit, and Chromium and the major three operating systems in order to deliver the best possible UX on every browser and every operating system.