The five different types of authentication

Authentication is how we prove our identity to access protected apps, services, and networks. 

There are many ways to authenticate, from simple usernames and passwords to more complex digital certificates, with each type varying from the next based on what it uses to verify identities, how secure it is, and how easy to implement.

In this article, we'll walk you through the five major authentication types and discuss how they work so you can decide when to use or avoid them.

Types of authentication

Authentication is the process of verifying a user's identity, typically through factors like emails, passcodes, or passkeys. It answers the question, "Who are you?".

There are lots of authentication methods out there, but they all generally fall under the following 5 types:

• Username and password: Requires a username and password.
• Multi-factor authentication: Requires multiple authentication layers like an SMS code on top of a password.
• Token-based authentication: Requires a digitally signed set of claims or assertions about a user to log in. 
• Certificate-based authentication: Uses digital certificates to verify identity.‍
• Biometric authentication: Essentially a form of certificate-based authentication that verifies identity using fingerprints, facial recognition, or other physical characteristics.

Username and password authentication

Username/password authentication is one of the most common authentication methods. A user is verified if their username (which could be an email) and password combination match what’s in the database.

A user creates an account with a unique username and a password which you store. When logging in, they enter their details which you compare against your database. If there’s a match, you grant them access.

Username/password authentication is simple to implement. At its most basic level, you only need a form where users can submit their details and a database for storage. 

It’s however notoriously prone to hacking — 65% of users always or mostly use the same password or a variation.

To limit the security risk, you can:

• Require strong, unique passwords.
• Always hash passwords before storing them.
• Combine passwords with multi-factor authentication like one-time codes sent via email (we’ll talk about this in the next section).
• Monitor for suspicious login activity and lock accounts after a certain number of failed login attempts.

Because of the security risks, username/password authentication is best suited for apps or services whose security is not a priority or just as a first line of defense in multi-factor authentication.

You should avoid username/password authentication when:

• Strong security is paramount, like in banking or health apps. Passwords can be guessed or stolen. 
• You need access controls. Username/password authentication lacks the granularity to specify detailed permissions.

Multi-Factor Authentication (MFA)

Multi-factor authentication (MFA) adds an extra layer of security to the authentication process. For example, after logging in with your password, the app might send a code to your email and then prompt you to enter the code before giving you access.

So, even if an attacker steals your password, they’ll still be locked out without the security code.

The most common ways MFA is implemented are:

• SMS text message: A one-time code is sent to the user’s registered phone number via text message, which you enter to log in.
• Authenticator app: An app like Google Authenticator or Authy generates a temporary code you enter.
• Hardware security key: After initial login, the user plugs the device (such as YubiKeys or Google Titan) into their computer or connects it via NFC or Bluetooth and presses a button on the device to authenticate.
• Push notifications: The user receives a push notification on a registered device, often through a dedicated authentication app. The user approves the login attempt directly from the notification.
• Biometric verification: After the initial login step, the system prompts the user for a biometric verification including fingerprint scanning, facial recognition, iris scanning, and voice recognition.

When implementing MFA, choose the factors that work best for your users and the level of security your data needs. Common combinations include password and code or password and fingerprint. 

You should also have a fallback authentication method, such as backup codes for when users don’t have their phones, for instance. Your number one goal should be to secure the app without deteriorating the user experience.

When to use MFA:

• Handling sensitive data: If your application deals with personal, financial, or any sensitive data, MFA is almost a necessity. It significantly reduces the risk of unauthorized access.

• User accounts with elevated privileges: For accounts that have administrative or elevated access within a system, use MFA for every additional privilege a user requests to prevent catastrophic security breaches.

When to avoid MFA:

• Low-risk applications: For apps whose data is not sensitive and the impact of a security breach is minimal.‍
• Situations requiring quick access: In emergency services or apps where speed of access is critical, the additional time required for MFA could be a hindrance.

Token-based authentication

Token-based authentication authenticates users through a service that issues tokens instead of directly handling their credentials. A token is a digitally encoded string that indicates a user’s authentication status.

With token-based authentication, client applications must attach a token to each request they make to your server. Only if the token is valid will the server grant a user access.

When a user tries to log in to an application, the application sends the user to a server that authenticates them and generates a token (like a JSON Web Token - JWT) containing their user’s details and permissions and sends it back to the application. The application then uses this token to access your app. If the token is valid, you grant them access.

Note that your app doesn’t necessarily have to be the one doing the authentication. In some cases, an external identity provider (like Google or Facebook, or an enterprise identity provider like Okta) authenticates the user on your behalf and generates a token verifying their identity. 

Your job is to make sure the token is valid: it’s not expired, it comes from an identity provider you trust, and it indicates the user is authenticated.

When to use tokens:

• Statelessness: Ideal for RESTful APIs and microservices architectures. Token-based authentication eliminates the need to make database calls as each request can be self-contained and independently authenticated.
• Supporting SSO: Users log in once into a central SSO service and use tokens to access connected apps.
• Outsource authentication: Suitable when outsourcing the complexities of authentication to identity providers. They authenticate users and issue tokens, which your app verifies.
• Fine-grained access control: Tokens can have scopes that specify the user’s roles, permissions, and resources they can access.

When to avoid token-based authentication:

• Long-term sessions: If your application requires long-term user sessions, token-based systems may not be ideal since tokens typically expire. You can avoid asking users to re-authenticate by generating fresh ones using refresh tokens.
• Highly sensitive transactions: For extremely sensitive apps requiring the highest level of security, relying solely on token-based authentication is not enough. If the token falls into the wrong hands, you risk a data breach.

Certificate-based authentication

Certificate-based authentication uses digital certificates to verify user identity. A digital certificate is issued by a trusted certificate authority (CA) and contains identifying information like the user’s name, the public key information, and a digital signature. The CA could be a public third-party authority (like VeriSign, DigiCert, Let's Encrypt, etc.) or a private CA (internal or proprietary) that you and your client mutually agree to use and trust.

The public key has a corresponding key — a private key stored by the user. Each private key is unique for each public key — this is the foundation of certificate-based authentication. Only if a user proves they have the private key that goes with the public key in the digital certificate do they get authenticated.

Here’s how it works:

• The user generates a key pair, a private key, and a public key, and sends the public key to a Certificate Authority (CA).
• The CA verifies the user and issues a digitally signed certificate containing the user's public key and identity data.
• The user securely stores the digital certificate and the matching private key.
• The user presents this certificate to a server when they want access.
• The server checks it for authenticity and then challenges the user to prove they hold the matching private key by sending a piece of data to the user, who encrypts it with their private key and sends it back.
• The server uses the public key in the certificate to decrypt the response. If successful, it confirms the user has the corresponding private key and is given access.

The security of the entire system depends on the private key remaining a secret.

When to use certificate-based authentication:

• Highly secure apps: You should use certificate-based authentication for highly secure apps. Users store their private keys in their OS, locally on the browser, or on dedicated hardware. The server never asks for the private key, only for proof of its existence. It never leaves the user’s possession, which reduces the risk of it getting stolen.

When you should avoid certificate-based authentication:

• Small-scale apps: For small-scale apps where the security risk is relatively low, using digital certificates is overkill.

Biometric authentication

Biometric authentication verifies users based on their unique physical characteristics, like fingerprints, facial recognition, or iris scans. This type of authentication is very secure since biometric data is difficult to replicate. It’s also more convenient for users since there are no passwords to remember.

Biometric authentication is essentially certificate-based authentication. The main difference is that the user’s biometric data (fingerprints or face scans) and private keys are securely stored on the user’s device inside of a special tamper-proof chip called a Hardware Security Module — like Apple’s Secure Enclave or a Trusted Platform Module. 

 When the user first creates their account on a service that supports biometrics, a certificate is generated inside the Hardware Security Module of their device and that certificate is sent to the service they are creating the account with. 

Note that the private key and the user’s biometric data are never sent to the service. During log-in, the Hardware Security Module will prompt the user to present their biometric data to complete the authentication. 

When to use biometric authentication:

• Convenience: Nearly all modern smartphones have fingerprint sensors or face recognition. You can leverage this to give your users an enjoyable login experience. They don’t have to authenticate; they can simply use their face ID or quickly tap the fingerprint sensor on their phone. 
• Secure apps: For apps handling sensitive data like financial transactions, personal data, or health records, biometric authentication adds an extra security layer.

When to avoid biometric authentication:

• Privacy concerns: Where users are sensitive about privacy, such as apps handling particularly personal data, the use of biometrics might raise concerns due to misunderstandings about how their biometric data is used.

Are there other, less common types of authentication?

Yes, there are, but they all broadly fall into the 5 types above. They are:

• Adaptive authentication: Adaptive authentication dynamically adjusts the authentication process based on the user's context, such as location or device. 
• Cognitive authentication: Verifies your identity based on your responses to personal questions or tasks uniquely known to you.
• Magic link authentication: You log in by clicking on an authentication link sent to your email.‍
• Device authentication: It verifies the identity of your device before giving you access.

What are the 3 AALs?

The NIST Authentication Assurance Levels (AALs) define the degree of confidence that digital identities are accurately verified and authenticated. Each level is tailored to the risk associated with the types of transactions users are allowed to perform once authenticated. 

• AAL1 (Authentication Assurance Level 1): AAL1 provides single-factor authentication, which requires only one factor to verify the user's identity. This factor can be something the user knows (e.g., a password), something the user has (e.g., a security token), or something the user is (e.g., biometric identification).
• AAL2 (Authentication Assurance Level 2): AAL2 requires two-factor authentication (2FA). This level enhances security by requiring two different authentication factors either a physical authenticator and a memorized secret, or a physical authenticator and a biometric that has been associated with it Additional security features at this level are replay resistance and shorter re-authentication times.
• AAL3 (Authentication Assurance Level 3): AAL requires multi-factor authentication with at least one hardware-based authenticator. AAL3 also features security requirements, including verifier impersonation resistance and verifier compromise resistance.

Next steps

If you're developing an enterprise app, Single Sign-On (SSO) is a must-have token-based authentication method for any SaaS looking to close large clients. 

Add it to your app in minutes with just a few lines of code using Unified SSO by WorkOS.

• Get started fast: With SDKs in every popular language, easy-to-follow documentation, and Slack-based support, you can implement SSO in minutes rather than weeks.
• Support every protocol: With OAuth 2.0 integrations to popular providers like Google and Microsoft, compatibility with every major IdP, and full support for custom SAML/OIDC connections, WorkOS can support any enterprise customer out of the box.
• Avoid the back-and-forth: WorkOS’s Admin Portal takes the pain out of onboarding your customers’ IT teams and configuring your app to work with their identity provider.
• Pricing that makes sense: Unlike competitors who price by monthly active users, WorkOS charges a flat rate for each company you onboard — whether they bring 10 or 10,000 SSO users to your app.

Explore Unified SSO by WorkOS.