Passwordless Authentication Using Passkey

In today's digital era, safeguarding user accounts is paramount for organizations offering online services. Halodoc, a leading player in Indonesia's healthcare sector, offers a wide array of digital healthcare services via web and mobile apps. With offerings ranging from telemedicine consultations to medication delivery and appointment scheduling, ensuring robust authentication methods is crucial to protect users from cyber threats. This blog delves into passkey authentication, a cutting-edge, passwordless approach that not only bolsters security but also streamlines user access, emerging as a secure, cost-effective solution for today's authentication needs.

What is Passkey ?

Passkeys serve as an alternative to passwords, offering a more convenient, secure, password-free sign-in process for websites and applications. Passkeys enable users to log in using security features found in user device like fingerprint, face recognition, pin etc. Passwords and other antiquated authentication methods are intended to be replaced by this technology.

The user's operating system or browser will assist them in choosing and using the correct passkey when they wish to log in to a service that employs them. The experience is akin to the current functionality of saved passwords. The system will prompt the user to unlock their device in order to verify that only the authorised user is able to use a passkey. A pattern, PIN, or biometric sensor (such a fingerprint or facial recognition system) may be used to accomplish this.

Why is Passkey the most secure and cost-effective authentication method?

Username-Password authentication has long been a ubiquitous method due to its straightforward implementation. However, its susceptibility to a plethora of cyber threats such as phishing, brute force attacks, and credential stuffing underscores the urgent need for a more resilient authentication framework. Single Sign-On (SSO) simplifies user authentication by allowing access to multiple applications with a single set of credentials. Yet, it introduces a single point of failure and potential privacy concerns related to user data sharing with the identity provider (IDP). Additionally, its integration with existing systems can be complex.

However, despite the security benefits, it's crucial to acknowledge that Two-Factor Authentication (2FA) is not entirely foolproof. One of the vulnerabilities associated with 2FA is the risk of Man-in-the-Middle (MIM) attacks. These attacks occur when an attacker intercepts communication between two parties, posing as one of them to obtain sensitive information. While 2FA significantly reduces the risk of unauthorized access and ensures compliance with regulatory standards, its implementation can incur substantial costs. Moreover, dependency on external services for OTP delivery introduces a potential disruption in user login attempts during downtime.

In contrast, passkey authentication represents a paradigm shift in security. By replacing traditional credentials with a private-public key pair, it mitigates the vulnerabilities associated with username-password methods. Passkeys offer heightened security, effectively resisting phishing attempts and credential stuffing attacks.Furthermore, they streamline the user experience by eliminating the need to manage multiple sets of credentials and by removing the necessity for OTP validation, thereby reducing operational costs typically incurred with OTP-based authentication methods.

Despite minor drawbacks such as initial setup complexity and adoption time, the benefits of passkey authentication far outweigh its challenges. Its implementation promises not only enhanced protection against cyber threats but also simplified user experiences and significant cost savings. Passkey authentication emerges as the optimal solution for modern authentication needs, offering a perfect balance of security, user convenience, and cost-effectiveness. Its adoption can lead to improved security postures and heightened user satisfaction, making it the preferred choice for organizations seeking robust authentication mechanisms in today's digital landscape.

Passkey Implementation

In this guide, we'll explore the implementation of passkey authentication on the server side, utilizing advanced public-private key cryptography for secure user authentication. We'll delve into the key elements of passkey setup, client-server interactions, and the function of authenticators. By the conclusion of this guide, you'll grasp a comprehensive understanding of the interaction between passkey components and be equipped to implement this robust authentication method effectively on your server.

Components Involved

• Backend Server (Relying Party): Relying party refers to the service or application that relies on the authentication process to grant access to its resources or features. Essentially, it's the entity that verifies the authentication tokens provided by the user or client application. In a server-side implementation of passkey authentication, the relying party would typically be the server or backend system that needs to authenticate users before granting them access to protected resources or functionalities. The relying party plays a crucial role in the authentication flow by validating the credentials or tokens provided by the user and authorizing access accordingly.
• Client: On the client (website or mobile app) side, users will need to generate a key pair using an authenticator. The private key is securely stored within the authenticator, while the public key is registered on the server for future authentication purposes.
• Authenticator: The authenticator plays a crucial role in the passkey authentication process. It is responsible for generating and securely storing the private key of the key pair used for authentication. Popular authenticator tools like Google Password Manager or iCloud provide users with a seamless way to manage their keys and ensure secure authentication across different applications.
  

Although it is technically feasible to use passkeys in an app without utilising third-party libraries, doing so is strongly discouraged because of the setup complexity and security challenges. For optimal passkey implementation in applications, choose one of the available libraries and adhere to its documentation.

Suggested Libraries:

• Java: java-webauthn-server
• Swift: AuthenticationServices
• Kotlin: Credential Manager

For website, we can use Web Authentication API (browser native API)

To start using passkey authentication, users first need to generate their passkey within the application. Once generated, the passkey is registered within the application for future use. Subsequently, users can utilize this registered passkey for seamless login experiences, eliminating the need for traditional username-password combinations. This streamlined approach enhances security and convenience for users.

Note: The upcoming discussion on passkey registration and authentication processes will be presented with the context of utilizing the Java-WebAuthn-Server library in the backend. This framework will serve as the foundation for our explanation, offering insights into the intricacies of passkey authentication within this environment.

Passkey Registration:

The first thing a user can do is create a new passkey in order to register for the service. There are two instances that merit discussion:

• The user wants to add passkey authentication to their existing account, which already has a username, password, and 2FA login. They will be able to add the passkey after signing in the traditional manner.
• Users can register with the service and associate a new passkey. In this instance, the generation of a new passkey and user will take place concurrently.
  

The registration procedure doesn't change in either of the two instances, even though the back-end logic might handle them differently. This procedure links a passkey to a service so that it can be accessed later.

Let’s explore the registration process:

• The user plans to use a client—either a website or a mobile app—to register for a service.
• By asking the relying party to register a new authenticator, the client starts the registration procedure.
• In response, the relying party provides a JSON (PublicKeyCredentialCreationOptions) that contains more metadata, including relying party details and approved authenticator types, along with a challenge. Furthermore, the challenge for this registration session is stored by the relying party because it must be validated upon receipt of the response.

{
  "challenge": "abc123",
  "rp": {
    "name": "Credential Manager example",
    "id": "credential-manager-test.example.com"
  },
  "user": {
    "id": "def456",
    "name": "helloandroid@gmail.com",
    "displayName": "helloandroid@gmail.com"
  },
  "pubKeyCredParams": [
    {
      "type": "public-key",
      "alg": -7
    },
    {
      "type": "public-key",
      "alg": -257
    }
  ],
  "timeout": 1800000,
  "attestation": "none",
  "excludeCredentials": [
    {"id": "ghi789", "type": "public-key"},
    {"id": "jkl012", "type": "public-key"}
  ],
  "authenticatorSelection": {
    "authenticatorAttachment": "platform",
    "requireResidentKey": true,
    "residentKey": "required",
    "userVerification": "required"
  }
}

• This response is used by the client to request that the authenticator create a new key pair, which will be used to verify the user's identity to the relying party.
• The authenticator checks the server payload and requests user identity (by device PIN or biometrics). The authenticator might be an external device or a smartphone.
• If all goes according to plan, the authenticator creates a new pair of private and public keys and sends the client a JSON (RegistrationResponseJSON) that includes the newly generated public key, attestation data, and other pertinent information. Note that the private key stays in the authenticator and, for smartphones, is kept in a different hardware part called the Trusted Execution Environment, or Secure Enclave.

{
  "id": "KEDetxZcUfinhVi6Za5nZQ",
  "type": "public-key",
  "rawId": "KEDetxZcUfinhVi6Za5nZQ",
  "response": {
    "clientDataJSON": "eyJ0eXBlIjoid2ViYXV0aG4uY3JlYXRlIiwiY2hhbGxlbmdlIjoibmhrUVhmRTU5SmI5N1Z5eU5Ka3ZEaVh1Y01Fdmx0ZHV2Y3JEbUdyT0RIWSIsIm9yaWdpbiI6ImFuZHJvaWQ6YXBrLWtleS1oYXNoOk1MTHpEdll4UTRFS1R3QzZVNlpWVnJGUXRIOEdjVi0xZDQ0NEZLOUh2YUkiLCJhbmRyb2lkUGFja2FnZU5hbWUiOiJjb20uZ29vZ2xlLmNyZWRlbnRpYWxtYW5hZ2VyLnNhbXBsZSJ9",
    "attestationObject": "o2NmbXRkbm9uZWdhdHRTdG10oGhhdXRoRGF0YViUj5r_fLFhV-qdmGEwiukwD5E_5ama9g0hzXgN8thcFGRdAAAAAAAAAAAAAAAAAAAAAAAAAAAAEChA3rcWXFH4p4VYumWuZ2WlAQIDJiABIVgg4RqZaJyaC24Pf4tT-8ONIZ5_Elddf3dNotGOx81jj3siWCAWXS6Lz70hvC2g8hwoLllOwlsbYatNkO2uYFO-eJID6A"
  }
}

• In order to validate and authenticate the new registration, the client forwards this attestation object to the relying party.
• The party, depending on the payload, confirms its receipt, authenticates the attestation object, and ensures that the user's registration satisfies the required standards (e.g., accurate challenge response, appropriate attestation format).
• The dependent party informs the user of the result after validating the registration payload. In the event that it is successful, pertinent data regarding the registered credential is stored and will be utilised for subsequent authentication.

Passkey Authentication:

The user can access a protected resource and authenticate with the relying party using the passkey once it has been registered. Now let's examine the process that enables the user to access the service:

Authentication Flow:

• The user needs to authenticate themselves in order to use a website or mobile app to access a service.
• By asking the relying party to authenticate, the client starts the authentication procedure.
• A JSON containing the authentication parameters (PublicKeyCredentialRequestOptions), along with a challenge and relying party details, is sent by the relying party. It also saves the challenge of this authentication session, which must be confirmed upon receiving the response.

{
  "challenge": "T1xCsnxM2DNL2KdK5CLa6fMhD7OBqho6syzInk_n-Uo",
  "allowCredentials": [],
  "timeout": 1800000,
  "userVerification": "required",
  "rpId": "credential-manager-app-test.glitch.me"
}

• The client requests that the authenticator sign this JSON with one of the passkeys associated with the relying party.
• The user is prompted to choose a passkey in order to continue with the authentication procedure if the authenticator has more than one passkey linked to the dependent party. After choosing, the user must authenticate themselves using either the device PIN or biometrics before they may use the private key that is stored in the authenticator to sign the challenge.
• The authenticator sends the client a JSON (AuthenticationResponseJSON) with the signed challenge, authenticator information, and other pertinent client data if the procedure is successful.

{
  "id": "KEDetxZcUfinhVi6Za5nZQ",
  "type": "public-key",
  "rawId": "KEDetxZcUfinhVi6Za5nZQ",
  "response": {
    "clientDataJSON": "eyJ0eXBlIjoid2ViYXV0aG4uZ2V0IiwiY2hhbGxlbmdlIjoiVDF4Q3NueE0yRE5MMktkSzVDTGE2Zk1oRDdPQnFobzZzeXpJbmtfbi1VbyIsIm9yaWdpbiI6ImFuZHJvaWQ6YXBrLWtleS1oYXNoOk1MTHpEdll4UTRFS1R3QzZVNlpWVnJGUXRIOEdjVi0xZDQ0NEZLOUh2YUkiLCJhbmRyb2lkUGFja2FnZU5hbWUiOiJjb20uZ29vZ2xlLmNyZWRlbnRpYWxtYW5hZ2VyLnNhbXBsZSJ9",
    "authenticatorData": "j5r_fLFhV-qdmGEwiukwD5E_5ama9g0hzXgN8thcFGQdAAAAAA",
    "signature": "MEUCIQCO1Cm4SA2xiG5FdKDHCJorueiS04wCsqHhiRDbbgITYAIgMKMFirgC2SSFmxrh7z9PzUqr0bK1HZ6Zn8vZVhETnyQ",
    "userHandle": "2HzoHm_hY0CjuEESY9tY6-3SdjmNHOoNqaPDcZGzsr0"
  }
}

• This authentication response is sent to the relying party by the client.
• First, the dependent party confirms that the authenticator being used is registered. Next, it verifies that the response is genuine and that the challenge response is accurate.
• Following a successful verification process, the relying party gives the user access to the service and lets them use it. In exchange, the relying party returns an authentication token that will be used for further requests.
  

Conclusion:

The initial adoption and implementation of passkey authentication at Halodoc are showing promising signs of success. We're witnessing a notable increase in user uptake, signaling a positive reception to the enhanced security and convenience it provides. Moreover, the evident reduction in costs associated with OTP delivery via SMS/WhatsApp highlights the efficiency of passkey authentication. Looking ahead, our commitment remains steadfast in harnessing innovative solutions like passkey authentication to continuously elevate user experiences and fortify security measures across our platform.

References:

Sign in your user with Credential Manager | Android Developers

Android Developers

Passwordless login with passkeys | Authentication | Google for Developers

Google for Developers

Join us

Scalability, reliability, and maintainability are the three pillars that govern what we build at Halodoc Tech. We are actively looking for engineers at all levels, and if solving hard problems with challenging requirements is your forte, please reach out to us with your resume at careers.india@halodoc.com.

About Halodoc

Halodoc is the pioneer of a digital health ecosystem with a mission to simplify healthcare access by addressing users’ pain points through accessible, reliable, and quality services. The company’s commitment to promoting wellness is reflected in the comprehensive range of health solutions, covering preventive to curative approaches, all within a single application.Since 2016, Halodoc has been enhancing health literacy in Indonesia through user-friendly healthcare Communication, Education, and Information (KIE). Our expanding ecosystem offers a range of convenient healthcare services, including Home Lab for home care health test; My Insurance for seamless access to cashless outpatient service benefits; Chat with Doctor teleconsultation with 20,000+ licensed doctors and health workers; as well as Health Store for access to purchase medicines, supplements, and various health products from 4,900+ trusted partner pharmacies. Halodoc has been recognized as one of a telehealth platform making a positive impact on the healthcare sector and received the “supervised” status in the Regulatory Sandbox program by the Ministry of Health of the Republic of Indonesia. It reflects a strong commitment and partnership between Halodoc and the MoH, ensuring participatory supervision to safeguard Digital Health Innovation (IDK) organizers, consumers and healthcare workers as the partner of digital innovations. The platform has also received a string of prestigious awards, including being featured on CB Insights’ Digital Health 150 list in 2019–2020 and receiving the Indonesian government’s 2023 PPKM Award. Download Halodoc app via iOS and Android.