Forem: Authgear

Passkey vs Password: Are Passkeys Safer Than Passwords? (2026)

Fung — Wed, 06 May 2026 14:56:48 +0000

Originally published at authgear.com.

tl;dr — Passkeys are cryptographic key pairs that replace passwords. The private key never leaves your device, so passkeys cannot be phished, guessed, or leaked in a server breach. The trade-off is recovery — lose all your devices and you fall back to email reset, just like passwords. In 2026 every major OS supports passkeys natively, so the comparison is now a real one.

In 2026, passkeys have moved from experiment to mainstream. Apple, Google, and Microsoft now support passkeys across all major platforms. Over 15 billion accounts can use passkeys. And the question developers and security teams ask most often is simple: are passkeys actually safer than passwords?

The short answer is yes — significantly. The longer answer explains exactly why, and what it means for your app.

Passkey vs password: head-to-head

Dimension	Password	Passkey
Storage	Memorised / password manager	Cryptographic key pair on device
Phishing-resistant	No — fake sites steal passwords	Yes — origin-bound, nothing to steal
Reusable across sites	Yes (a vulnerability)	No — per-site key pair
Server breach exposure	Whole password at risk	Public key only — useless without your device
Brute-force-resistant	Depends on length and complexity	Yes — cryptographic key, not a guessable string
Cross-device	User must remember or sync via manager	Synced via Apple Keychain, Google Password Manager, or 1Password
Recovery if all devices lost	Email reset	Email reset (same fallback)
User typing required	Yes	No — Face ID, Touch ID, or PIN tap
NIST AAL level	AAL1	AAL2 (single-factor passkey with user verification)

Passkey vs password: which is safer in 2026?

Passkeys are safer than passwords in every measurable way. Here's why:

Passkeys cannot be phished. When you log in with a passkey, your device signs a challenge from the server using a private key that never leaves your device. A fake login page gets nothing — there's no password to steal.
Passkeys cannot be reused. Each passkey is unique to the website it was created for. A passkey for your banking app cannot be used on any other site, even if the attacker controls the other site.
Passkeys cannot be guessed. Passkeys are cryptographic keys generated randomly. There is no equivalent of "password123" or a dictionary attack.
Passkeys cannot be leaked in bulk. Servers only store your public key — even if a server is breached, attackers get a public key that is useless without the private key on your device.

According to Google, accounts with passkeys are 99.9% less likely to be compromised than those relying on passwords alone. Phishing and credential stuffing — responsible for the majority of account takeovers — simply don't work against passkeys.

Understanding Passkeys: How They Work

A passkey is a pair of cryptographic keys: a private key stored securely on your device, and a public key stored on the server. Here's what happens when you log in:

The server sends a unique challenge to your device
Your device uses Face ID, Touch ID, or PIN to unlock the private key
The private key signs the challenge
The server verifies the signature using your public key
You're in — without sending any secret over the internet

Think of it like a safe deposit box. The bank holds the lock (your public key). Only your key (private key, on your device) can open it. The bank never sees your key, and you never share it.

Key benefits at a glance:

Phishing-resistant: Nothing to steal — your private key never leaves your device
No passwords to remember: Authentication via biometric (Face ID, fingerprint) or device PIN
Cross-device sync: Passkeys sync across your devices via Apple Keychain, Google Password Manager, or 1Password
Works everywhere: iOS, Android, Windows, macOS, Chrome, Safari, Firefox

Why Passwords Are No Longer Enough

Passwords have been the primary authentication method for 60 years, and they're failing us. Here's why:

Weak passwords: 80% of breaches involve weak or reused passwords (Verizon DBIR 2025). Users choose memorable over secure.
Password reuse: The average person reuses passwords across 5+ accounts. One breach exposes all of them.
Phishing: Even sophisticated users get fooled. Phishing attacks are responsible for 36% of data breaches.
Data breaches: 26 billion records were leaked in the "Mother of All Breaches" in early 2024. Those passwords are now on the dark web.
Password fatigue: The average person manages 100+ passwords. The cognitive load drives risky behavior (writing down passwords, reusing them).

The core problem: passwords are secrets shared with a server. Every time you log in, you send your secret over the internet. Every server that stores your password is a potential breach. Passkeys eliminate this entirely.

Passkeys vs passwords: full feature comparison (2026)

Feature	Password	Passkey
Security model	Shared secret (stored on server)	Public-key cryptography (private key never leaves device)
Phishing resistance	❌ Vulnerable — fake sites steal passwords easily	✅ Immune — passkeys are bound to the domain they were created for
Brute-force resistance	❌ Weak passwords are cracked in seconds	✅ No password to crack
Credential stuffing	❌ At risk if passwords are reused	✅ Each passkey is unique per site
Data breach exposure	❌ Passwords exposed if server is breached	✅ Only public key stored — useless alone
User experience	❌ Remember and type a password	✅ Biometric or PIN tap
Login speed	⚠️ Slower — type password + optional MFA	✅ Faster — one biometric tap
Cross-device sync	❌ No (password managers partially solve this)	✅ Yes (iCloud Keychain, Google Password Manager)
MFA requirement	⚠️ Recommended but often skipped	✅ Built-in (device PIN/biometric is the second factor)
Lost device recovery	⚠️ Password still works from other devices	⚠️ Recovery via backup passkeys or account recovery flow
Platform support (2026)	✅ Universal	✅ iOS, Android, Windows, macOS, major browsers
Implementation cost	⚠️ Low (passwords are simple)	⚠️ Medium (WebAuthn API or auth platform like Authgear)

Passkeys in 2026: Real-World Adoption

Passkeys have crossed the tipping point from "interesting experiment" to "production standard." Here's where things stand in 2026:

15 billion accounts can now authenticate with passkeys, according to the FIDO Alliance (2026).
Google: Passkey sign-ins surpassed 1 billion per month in late 2025 (Google Identity blog), with a 99.9% lower account compromise rate than passwords.
Apple: Passkeys are the default sign-in method for new iCloud accounts — announced at WWDC 2025.
Microsoft: "Passwordless by default" for new Microsoft 365 accounts since 2025. Passkeys are the encouraged replacement.
GitHub: Passkeys available for all 100M+ users since early 2024.
Amazon: Passkeys available for shopping accounts across the US, UK, and Australia.

For developers, the message is clear: users increasingly expect passkey support. Apps without passkeys will feel dated within 12–18 months.

Password vs passkey: which is easier for users?

Passkeys win on ease of use — not just security.

Signing in with a password involves recalling or retrieving a credential, typing it (with a risk of typos), and often completing a second-factor step such as entering an SMS code or an authenticator app TOTP. Average sign-in time for a password + SMS-OTP flow is roughly 20–30 seconds.

Signing in with a passkey involves a single biometric prompt — Face ID, Touch ID, or a device PIN tap. No typing, no copy-pasting, no switching apps. Average sign-in time drops to 2–3 seconds.

Other UX differences worth noting:

Account creation: Passkey enrolment requires a single biometric tap after the initial sign-up. No "create a strong password" friction, no password-confirmation field.
Recovery flow: The trade-off is here. If a user loses all their devices, passkey recovery falls back to email verification or a backup code — the same friction as a password reset. It is no worse, but it is no better. Design a clear recovery path before you go passkey-only.
Password managers as a comparison: Password managers remove the memorisation burden, but users still type. They also require the manager app to be installed and unlocked. Passkeys are the keychain, built into the OS — nothing extra to install.
One-tap login UX: Modern passkey prompts appear automatically when a registered device is detected. Returning users often sign in without touching a keyboard at all. This is the UX that makes passkeys compelling for consumer apps where login friction directly affects conversion rate.

The UX case for passkeys is strong enough that Google's internal data shows passkey sign-ins are 4× faster than passwords.

Are passkeys 2FA or MFA?

This question comes up often because it matters for compliance. The precise answer is: a passkey alone is a single factor ("something you have" — the device), but in practice it always requires user verification, which adds a second factor ("something you are" with biometrics, or "something you know" with a PIN).

What NIST says: NIST SP 800-63B classifies a passkey used with user verification as AAL2 — the same level as a password plus an authenticator app. AAL3 (the highest level, required for federal systems and some financial regulators) additionally requires a hardware-bound authenticator that resists physical extraction; a passkey synced to the cloud does not qualify, but a device-bound passkey on a hardware key like a YubiKey does.

Practical implications for developers:

For most consumer and B2B apps, a passkey replaces both the password and the SMS-OTP or authenticator app. You can remove the separate 2FA step entirely — the passkey prompt already satisfies it.
For regulated sectors (banking under FFIEC, US federal apps requiring FIDO2 at AAL3), check whether your regulator explicitly requires separate authentication channels. In those cases, a synced passkey may be AAL2 but not AAL3, and an additional hardware-bound token may still be required.
For enterprise apps enforcing MFA policies, passkeys satisfy most "MFA required" rules — but verify with your IdP (Authgear, Okta, Azure AD) that the policy recognises passkey sign-ins as multi-factor events.

Bottom line: For the overwhelming majority of apps, a passkey replaces password + 2FA as a single, simpler step. If you are building in a highly regulated environment, verify your specific AAL requirements before removing the separate MFA step.

Passkeys vs Passwords: Which Should You Use?

The answer is almost always passkeys — but a phased approach is practical:

New apps: Implement passkeys from day one. Use a platform like Authgear that provides passkey support with a few lines of code.
Existing apps: Add passkeys as a login option alongside passwords. Let users opt in. Most will — passkeys are easier to use.
Enterprise apps: If you use Active Directory / LDAP internally, you can still add passkeys for external-facing applications while keeping your internal directory.
Legacy systems: If passkey support is truly impossible, at minimum enforce MFA on all accounts to close the worst password vulnerabilities.

How to Enable Passkeys in Your App with Authgear

Implementing passkeys from scratch requires handling WebAuthn registration, authentication challenges, key storage, and cross-device sync — a significant engineering effort. Authgear provides passkey support out of the box.

With Authgear, enabling passkeys takes minutes, not weeks:

Enable passkeys in the Authgear Portal: Go to Authentication → Login Methods → Passkeys and toggle them on. No code required.
Choose your strategy — passkeys + passwords (users pick), passkeys only (enforce passwordless), or passkeys for new users while keeping passwords for existing ones (gradual migration).
Add the Authgear SDK to your app: Available for React, Next.js, React Native, Flutter, iOS, Android, and more.
Test on supported devices: iOS 16+, Android 9+, Chrome 108+, Safari 16+, Edge 109+

Your users authenticate with Face ID, Touch ID, or PIN — and you handle zero credential storage, no password resets, and no phishing risk.

Learn more about Authgear passkeys →

The Future of Authentication

The writing is on the wall: passwords are on their way out. The transition is already happening across every major platform. As passkey adoption grows, expect:

Passwordless by default: More platforms will make passkeys the default login method, not an option
Passkeys for payments: Strong customer authentication (SCA) requirements in finance will push passkey adoption in banking and fintech
AI-resistant authentication: As AI makes social engineering more sophisticated, phishing-resistant passkeys become more critical, not less
Shared device scenarios: Work is ongoing for enterprise managed-device passkey scenarios, filling the last remaining gap

The era of passwords is drawing to a close. Apps that adopt passkeys today will have a security and UX advantage tomorrow.

Frequently Asked Questions

What is a passkey vs a password?

A password is a secret string you create and remember (or store in a password manager). A passkey is a cryptographic key pair — a private key stored on your device and a public key stored on the server. You never type a passkey; instead, you authenticate with Face ID, Touch ID, or a PIN. Passkeys are more secure because they can't be phished, guessed, or leaked in a data breach.

Are passkeys safer than passwords?

Yes, significantly. Passkeys are phishing-resistant (fake sites can't steal them), brute-force-resistant (cryptographic keys can't be guessed), and breach-resistant (servers only store public keys, which are useless without your device). Google reports passkey accounts have a 99.9% lower compromise rate than password accounts.

Can passkeys replace two-factor authentication (2FA)?

Yes. A passkey combines something you have (your device) with something you are (your biometric) or something you know (your PIN). This makes a passkey equivalent to a password plus a second factor — you don't need a separate SMS code or authenticator app. Passkeys meet or exceed NIST AAL2 authentication requirements.

What happens if I lose my device?

Passkeys sync across your devices via Apple Keychain, Google Password Manager, or a cross-platform manager like 1Password. If you lose one device, you can still log in from another. For users without a second device, most services provide account recovery via email verification or a backup code — just like password resets today.

Do passkeys work on all browsers and devices?

In 2026, passkeys work on the vast majority of devices: iOS 16+, Android 9+, Windows 10+ with Windows Hello, macOS 13+ with Touch ID, and all major browsers (Chrome 108+, Safari 16+, Firefox 122+, Edge 109+). For older devices, passkey-enabled services typically still offer password fallback.

How do I add passkey support to my app?

You can implement passkeys directly using the WebAuthn API (built into modern browsers) or use an authentication platform like Authgear that handles the complexity for you. Authgear supports passkeys across all major platforms with a few lines of SDK code and a configuration toggle in the portal.

Originally published at authgear.com. Authgear is an authentication platform for modern apps — passkeys, MFA, SSO, session management.

SSL Certificate Chain: What It Is and How to Fix It

Fung — Wed, 06 May 2026 14:40:14 +0000

Originally published at authgear.com.

tl;dr — An SSL certificate chain is the sequence of digital certificates that links your website's certificate to a root Certificate Authority (CA) browsers trust: your leaf certificate → one or more intermediate certificates → a trusted root certificate. Your server must send the leaf and intermediates; the root is pre-installed in the client. If any intermediate is missing, mobile browsers and API clients fail — even though desktop Chrome may still work due to caching.

What Is an SSL Certificate Chain?

An SSL certificate chain — also called a certificate trust chain or chain of trust — is a sequence of certificates that connects your website's certificate back to a root Certificate Authority (CA) that browsers inherently trust.

Think of it like a chain of vouchers: your site's certificate is vouched for by an intermediate CA, which is in turn vouched for by a root CA. Browsers come pre-installed with a list of trusted root CAs. If a browser can follow the chain from your certificate up to a trusted root without any gaps, the connection is trusted. If any link in the chain is missing, the browser shows a security error — even if your certificate itself is perfectly valid.

💡 New to SSL certificates? Before diving into chains, you may want to read What Is an SSL Certificate? A Developer's Guide for an overview of how certificates work.

The Three Levels of a Certificate Chain

Every certificate chain has the same structure, regardless of which CA issued your certificate:

Level	Name	What It Is	Who Provides It
1 (leaf)	Leaf certificate	The certificate issued to your specific domain	You — installed on your web server
2 (middle)	Intermediate certificate(s)	Issued by the root CA to authorize an intermediate CA to issue domain certificates	Your CA — must also be served by your web server
3 (root)	Root certificate	Self-signed certificate from a trusted root CA	The CA — pre-installed in browsers and operating systems

When a browser connects to your site, your server sends the leaf certificate and any intermediate certificates. The browser checks whether the chain connects to a trusted root in its built-in trust store. The root certificate itself is never sent by the server — it's expected to already be present on the client.

Why the Chain Exists: Root CAs Stay Offline

Root CA private keys are among the most sensitive secrets in internet infrastructure. A compromised root CA could be used to forge trusted certificates for any website in the world — banks, governments, email providers, anything. To protect root private keys, root CAs are kept offline, physically air-gapped from the internet.

Because root CAs are offline, they can't sign website certificates directly. Instead, they issue intermediate CA certificates to subordinate authorities who do the day-to-day work of signing domain certificates. If an intermediate CA is ever compromised, it can be revoked without touching the root CA or invalidating the entire trust hierarchy.

This is why your server is responsible for serving the intermediate certificate. The root is assumed to be in the client's trust store. Everything between your leaf certificate and the root must come from your server.

The Most Common Chain Error: Missing Intermediate Certificate

The single most frequent SSL misconfiguration is a missing intermediate certificate. Your leaf certificate is installed, but the intermediate CA certificate is not being served alongside it.

Here's why this error is so deceptive:

Desktop browsers often cache intermediates — Chrome and Firefox maintain a local cache of intermediate certificates they've encountered before. If a previous site used the same intermediate CA, the browser already has it and won't notice your missing intermediate.
Mobile browsers don't cache — iOS Safari, Android Chrome on fresh installs, and most mobile browsers will fail immediately if the intermediate is missing from the server response.
API clients and server-to-server calls always fail — curl, Python's requests, Node's https module, Java's HttpClient, and nearly every backend HTTP library do not cache intermediates. They reject the connection outright.

This is why a misconfigured chain can pass all your desktop browser testing and still silently break mobile users and backend API integrations in production.

⚠️ Classic incident pattern: You deploy a renewed certificate. Desktop Chrome works fine (it had the intermediate cached from your previous cert). You close the ticket. Three hours later, the mobile app team reports that all API calls are failing with SSL errors. The server is only sending the leaf certificate — no intermediate.

How to Check Your Certificate Chain

Option 1: Authgear SSL Certificate Chain Checker (recommended)

Use the Authgear SSL Checker to visualize your full certificate chain. It shows each level — leaf certificate, intermediate(s), and root — and immediately flags if any intermediates are missing or if the chain fails to connect to a trusted root.

🔒 Run this after every certificate renewal. Let's Encrypt's Certbot correctly configures the chain when you use fullchain.pem — but if you manually install a paid CA certificate, it's easy to accidentally deploy only the leaf certificate. The SSL Checker catches this instantly.

Option 2: OpenSSL (command line)

You can inspect exactly what your server is serving with OpenSSL:

# View the full certificate chain your server is sending
openssl s_client -connect yourdomain.com:443 -showcerts

# Count the number of BEGIN CERTIFICATE blocks in the output:
# - 2 blocks: leaf + one intermediate (normal for Let's Encrypt)
# - 1 block: leaf only — your intermediate is missing

If you see only one BEGIN CERTIFICATE block, your server is sending only the leaf certificate. The chain is incomplete.

What a Decoded Certificate Chain Looks Like

To see what's actually inside each certificate in the chain, decode them with openssl x509 -text -noout. Here's a real example from cloudflare.com (truncated for readability):

# Leaf certificate
Subject: CN = cloudflare.com
Issuer:  C = US, O = Google Trust Services, CN = WE1
Validity:
    Not Before: Apr  3 00:00:00 2026 GMT
    Not After : Jun 30 23:59:59 2026 GMT
Signature Algorithm: ecdsa-with-SHA256
Subject Alternative Name:
    DNS:cloudflare.com, DNS:*.cloudflare.com, ...

# Intermediate certificate (the one your server must also send)
Subject: C = US, O = Google Trust Services, CN = WE1
Issuer:  C = US, O = Google Trust Services LLC, CN = GTS Root R4
Validity:
    Not Before: Dec 13 09:00:00 2023 GMT
    Not After : Feb 20 14:00:00 2029 GMT
Signature Algorithm: ecdsa-with-SHA384

# Root certificate (NOT sent by the server — already in the client trust store)
Subject: C = US, O = Google Trust Services LLC, CN = GTS Root R4
Issuer:  C = US, O = Google Trust Services LLC, CN = GTS Root R4    ← self-signed
Signature Algorithm: ecdsa-with-SHA384

Notice the pattern: the issuer of each certificate matches the subject of the certificate above it. That's how the browser walks the chain. The root certificate is self-signed — its subject and issuer are identical — and it's the one your server doesn't send because it has to already be in the client's trust store.

How to Fix a Broken Certificate Chain

The fix is always the same concept: configure your web server to send the intermediate certificate alongside your leaf certificate. The exact steps depend on your server and how you obtained your certificate.

If you used Certbot (Let's Encrypt)

Certbot generates several certificate files in /etc/letsencrypt/live/yourdomain.com/. The most common mistake is using the wrong one:

# fullchain.pem   — Use this: leaf certificate + intermediate(s) combined
# cert.pem        — Not this: leaf certificate only (no intermediate)
# chain.pem       — Intermediate certificate only
# privkey.pem     — Your private key

In your web server config, always reference fullchain.pem as your certificate file, not cert.pem.

Nginx

server {
    listen 443 ssl;
    server_name yourdomain.com;
    ssl_certificate     /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;
}

Apache

<VirtualHost *:443>
    ServerName yourdomain.com
    SSLEngine on
    SSLCertificateFile    /etc/letsencrypt/live/yourdomain.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/yourdomain.com/privkey.pem
</VirtualHost>

Caddy

yourdomain.com {
    reverse_proxy localhost:3000
}

# If providing your own certificate manually:
yourdomain.com {
    tls /path/to/fullchain.pem /path/to/privkey.pem
}

If using a paid CA (manual certificate)

# Combine leaf and intermediate (leaf first, then intermediate)
cat yourdomain.crt intermediate.crt > fullchain.crt

After updating your config, reload your server and verify the fix with the Authgear SSL Checker.

How to Prevent Chain Issues

Always use fullchain.pem when using Certbot — never reference cert.pem alone.
Test from a clean environment — use the Authgear SSL Checker, which always connects fresh without cached intermediates.
Test after every certificate change — check the chain immediately after deploying, before closing the deployment window.
Set up expiry monitoring — tools like UptimeRobot, Checkly, or Datadog can alert you before a certificate expires or the chain becomes invalid.

Frequently Asked Questions

What is an SSL certificate chain?

An SSL certificate chain is the sequence of digital certificates that links your website's certificate to a root Certificate Authority (CA) that browsers trust. The chain typically has three levels: your leaf certificate, one or more intermediate certificates, and a trusted root certificate.

How does an SSL certificate chain work?

When a browser connects to your site, your server sends the leaf certificate plus any intermediate certificates. The browser walks the chain upward, verifying each certificate's signature, until it reaches a root certificate already in its trust store. If every link checks out, the connection is trusted. If the chain breaks anywhere, the browser shows a security error.

What is the difference between a certificate and a certificate chain?

A certificate is a single signed credential proving ownership of a domain or identity. A certificate chain is the full path from your certificate up to a trusted root, including every intermediate certificate that signed something below it. Browsers trust roots, not individual leaf certificates — the chain is what proves your certificate was issued by a trusted authority.

What does a certificate chain look like?

When decoded with openssl x509 -text, each certificate in the chain shows its subject (who it identifies), issuer (who signed it), validity dates, and signature algorithm. In a valid chain, the issuer of certificate N matches the subject of certificate N+1, all the way up to a self-signed root. See the decoded example above.

Why is my certificate chain incomplete?

The most common cause is referencing the wrong file in your web server config. With Certbot, use fullchain.pem (leaf + intermediate) — not cert.pem (leaf only). With a paid CA, you may need to manually concatenate the leaf and intermediate certificates into a single file before deployment.

What is fullchain.pem?

fullchain.pem is the file Certbot generates that contains your leaf certificate followed by every intermediate certificate, concatenated in PEM format. Always reference this file in your Nginx, Apache, or Caddy configuration — never cert.pem, which is the leaf certificate alone and will produce a broken chain.

Next Steps

Check your certificate chain with the free Authgear SSL Checker
Learn the fundamentals in What Is an SSL Certificate? A Developer's Guide

Originally published at authgear.com. Authgear is an authentication platform for modern apps — passkeys, MFA, SSO, session management.

Testing HMAC Signatures Online — A Free Developer Tool

Fung — Wed, 08 Oct 2025 16:21:39 +0000

APIs often rely on HMAC signatures to verify the authenticity and integrity of requests.
Whether you’re validating webhooks, securing IoT messages, or signing API payloads, it’s crucial to confirm that your HMAC implementation works correctly — and that both client and server generate the same signature.

That’s where a free testing tool helps.

🔐 What Is an HMAC Signature?

An HMAC (Hash-based Message Authentication Code) is a unique signature generated by hashing a message with a secret key.
If the message changes or the key is incorrect, the signature won’t match — protecting your API from tampering or replay attacks.

Example:

HMAC = hash(secret_key + message)

Common algorithms: SHA-256, SHA-1, SHA-512

🧮 Why You Need to Test HMAC Signatures

When integrating APIs, mismatched HMAC signatures are among the most common debugging issues.
You might face:

Incorrect encoding (UTF-8 vs ASCII)
Mismatched algorithms (SHA1 vs SHA256)
Differences in message formatting
Missing newline characters or whitespace

Testing with a live HMAC tool helps quickly isolate these problems before they break production code.

🧰 Free Tool: HMAC Signature Generator & Verifier

You can instantly generate or verify HMAC signatures using this free tool:

👉 HMAC Signature Generator & Verifier — by Authgear

Features:

Supports SHA-1, SHA-256, and SHA-512
“Generate” or “Verify” modes
Copy-to-clipboard output
Real-time hash calculation
No account or API key required

How to Use It:

Paste your message.
Enter your secret key.
Choose the hash algorithm (e.g., SHA-256).
Click Generate to get your signature — or switch to Verify mode to compare an existing one.

It’s a simple way to confirm that your backend code is producing the same HMAC value you expect.

🧑‍💻 Quick Example in Node.js

const crypto = require('crypto');
const message = 'Hello from Authgear';
const secret = 'mysecretkey';

const signature = crypto
  .createHmac('sha256', secret)
  .update(message)
  .digest('hex');

console.log('Generated HMAC:', signature);

You can paste your message and secret into the Authgear HMAC tool to verify the result instantly.

🌐 Why Developers Use HMAC

Lightweight and fast
Works offline (no tokens or external verification)
Easy to implement in any language
Still one of the most secure message verification methods in 2025

SSO Simplified: Enhancing Security and User Experience

Fung — Mon, 02 Sep 2024 05:27:52 +0000

Single Sign-On (SSO) has become a cornerstone of modern digital authentication strategies. In essence, SSO allows users to access multiple applications and services with a single set of credentials, streamlining the user experience and enhancing security. For IT managers and technicians, implementing SSO effectively can significantly reduce password fatigue, minimize security risks, and improve overall productivity.

This handbook article aims to provide a deep dive into SSO technologies, exploring various implementation scenarios, underlying mechanisms, and best practices. By the end of this guide, you'll be equipped with the knowledge to make informed decisions about SSO deployment in your organization.

1. Scenarios Where SSO is Needed

1.1 Multi-app Ecosystem

Large tech companies often operate diverse portfolios of applications and services. SSO plays a crucial role in unifying these ecosystems:

Meta: Facebook, Instagram, Messenger, and Threads form a tightly integrated social media ecosystem. Users can seamlessly switch between these platforms without re-authenticating, enhancing engagement and cross-platform interactions.
Google: The suite including Google Photos, Drive, Maps, and Home devices showcases how SSO can span both web and IoT environments. A single Google account provides access to a vast array of services, from productivity tools to smart home controls.
Uber: By unifying Uber ride-hailing, UberEats food delivery, and the Uber Drivers app under a single authentication system, the company provides a cohesive experience for both customers and service providers.

In these ecosystems, SSO not only enhances user experience but also allows for more effective data sharing and personalization across services, while maintaining robust security protocols, even if the apps were all built by completely different teams.

1.2 Spin-off Apps and Campaigns

Enterprises frequently launch new initiatives that require rapid development and deployment. This often includes spin-off projects, and prototype testing of new product concepts. In such cases, Single Sign-On (SSO) can be a crucial tool.

For marketing campaigns requiring quick web apps, SSO allows these temporary applications to securely use existing user bases. SSO also streamlines user onboarding for new ventures by tapping into the parent company’s user pool and facilitates prototype testing with a subset of existing users without creating new authentication systems.

Sometimes, the development team of the core app may be too busy to respond quickly to requests for new initiatives, such as a web app for a marketing campaign. Having an SSO infrastructure in place can empower a small development and design team to iterate rapidly.

By implementing SSO, organizations can maintain agility in launching new initiatives while ensuring that user data remains protected and consistent across all touchpoints.

1.3 Super Apps with Mini Programs

The concept of super apps, popularized in Asian markets, is gaining traction globally, with some popular examples including:

LINE/KakaoTalk: These super apps incorporate messaging, social media, and a vast ecosystem of mini-programs, all accessible through a single login.
Gojek: In Southeast Asia, Gojek offers ride-hailing, food delivery, news, and financial services within a single app.

Super apps can also be found within enterprise environments, where they offer significant advantages:

Corporate Portals: Instead of asking staff to install multiple different apps, an enterprise may package various internal tools into a single mobile app. This super app can include systems like HR, inventory management, and communication platforms, all built by different developers or business units.
Field Service Apps: Companies with mobile workforces, such as maintenance or IT, can bundle multiple tools (scheduling, invoicing, knowledge bases) into one app with SSO. This approach provides employees with seamless access to all necessary resources in one place.

In both cases, services must be accessible on mobile platforms and web browsers. Delivering these services as web apps is cost-effective and ensures they are always up-to-date. However, implementing SSO in super apps presents unique challenges, particularly in managing session states across different mini-programs or web views.

A secure SSO mechanism helps manage sessions across the app suite, allowing for smooth transitions between services while maintaining strict security boundaries. IT professionals must ensure seamless integration between various services to provide an efficient user experience and uphold high security standards.

1.4 App-to-App Authentication

App-to-app (app2app) authentication is becoming increasingly important in mobile ecosystems, as it offers a simpler and faster flow for authentication when the user has already installed and logged into another recognized app on their mobile device. Here are some key use cases:

Financial Services: Banking apps can authorize fintech apps to access account information, streamlining processes like budgeting or investment management.

This integration allows users to seamlessly manage their finances across multiple platforms within a single application.

Implementing app2app authentication requires careful consideration of security protocols, user consent mechanisms, and data sharing policies. IT managers must ensure compliance with regulations like GDPR or PSD2 when implementing these solutions.

2. How Sessions are Shared Between Services

2.1 Cookies

Cookie-based SSO is one of the most straightforward and essential methods for authenticating users in web applications. It offers several advantages such as:

Domain-Level Sharing: By configuring cookies at the root domain level (e.g., .example.com), all subdomains can access the same session information, making it easier to manage user sessions across multiple subdomains.
Secure and HttpOnly Flags: These flags enhance security by restricting client-side access to cookies and ensuring that they are only transmitted over secure channels.
SameSite Attribute: This attribute helps mitigate cross-site request forgery (CSRF) attacks by controlling how cookies are included with cross-site requests.

2.2 Redirect Flow

You tap "Login" in an app, and it whisks you away to a familiar login page in your browser. After entering your credentials, you're seamlessly transported back to the app, now fully logged in. This smooth back-and-forth dance is known as the "redirect flow" - a typical implementation of Single Sign-On (SSO) technology.

This seamless experience extends across multiple apps. When a new app redirects you to the same login page, you'll often find your session is still active. With just a quick "Continue" tap, you're in - no need to re-enter your credentials.

The redirect flow is crucial for implementing SSO in cross-platform applications and requires secure token exchange mechanisms such as:

OAuth 2.0 and OpenID Connect: These protocols standardize the authorization and authentication processes, allowing for secure token exchange.
State Parameter: This prevents CSRF attacks by ensuring the request's integrity throughout the redirect process.
PKCE (Proof Key for Code Exchange): An additional security layer for mobile and single-page applications to prevent interception of the authorization code.

Here’s an example flow:

User clicks "Login" in App A
App A redirects to centralized auth server with client_id and redirect_uri
User authenticates on auth server
Auth server redirects back to App A with an authorization code
App A exchanges code for access and refresh tokens
App A can now make authenticated API calls

Implementing this flow requires careful coordination between the client application, authorization server, and resource server to ensure secure token handling and validation.

2.3 Shared Container

Imagine this: You download the new shiny app Google just released, and it instantly opens to your personalized dashboard without asking you to log in or provide details. No email entry, no password prompt — just immediate access. Real-life magic.

This is where shared containers come in.

Shared containers provide a native SSO experience on mobile platforms:

iOS Keychain and App Groups: Allow secure sharing of credentials between apps from the same developer.
Android AccountManager: Provides a centralized registry of user credentials that can be securely accessed by authorized apps.

This example demonstrates how to securely store and retrieve authentication tokens using the iOS Keychain, which can be shared between apps from the same developer.

3. Choosing the Right SSO Approach

Selecting the appropriate SSO method depends on various factors:

Platform Diversity:
- Web-only: For non-SPA websites, consider cookie-based solutions. For other applications requiring web-specific SSO protocols you can consider using redirect flow.
- Mixed (Web and Mobile): Implement OAuth 2.0 with OpenID Connect for a standardized approach across platforms.
- Mobile-only: Utilize platform-specific shared containers or app2app authentication.
Security Requirements:
- High-security environments may require additional factors like biometrics or hardware tokens.
- Consider implementing FIDO2 standards for passwordless authentication.
User Experience:
- Evaluate the trade-off between security and convenience.
- Consider implementing step-up authentication for sensitive operations.
Regulatory Compliance:
- Ensure your SSO solution adheres to relevant standards (e.g., GDPR, HIPAA, PSD2).
- Implement appropriate consent and data sharing mechanisms.
Scalability:
- Choose solutions that can grow with your user base and application ecosystem.
- Consider cloud-based identity providers for easier management and scalability.

Taking a thoughtful approach to these considerations will not only enhance security but also streamline access across diverse platforms, ultimately supporting a seamless and efficient user experience.

Conclusion

Implementing SSO effectively requires a deep understanding of various technologies and careful consideration of your organization's specific needs. By leveraging the right combination of cookies, redirect flows, shared containers, and app2app authentication, you can create a seamless and secure authentication experience across your entire digital ecosystem.

As you move forward with your SSO implementation, remember to:

Regularly audit your authentication systems for security vulnerabilities.
Stay informed about emerging authentication standards and best practices.
Collect and analyze user feedback to continuously improve the login experience.
Plan for future expansion of your application ecosystem and how it will integrate with your SSO solution.

By following these guidelines and choosing the appropriate SSO methods for your use cases, you can significantly enhance both the security and usability of your organization's digital services.

This article is part of a multi-part handbook. If you're interested, follow for more upcoming posts about SSO or join our auth-oriented community