Getting Started with Passkeys in the Digital World
Hey there, if you've been diving into modern web tech, you might've come across passkeys—they're like the cool new way to ditch those pesky passwords for good. But here's a head-scratcher that pops up a lot: even with all this fancy passwordless magic, why do you still have to set up an account with a username or email, and sometimes even a traditional password, right at the beginning? Let's break it down step by step, like we're chatting over coffee.
The Basics of What Passkeys Actually Do
Imagine passkeys as your personal digital keychain, powered by tech like WebAuthn standards. They're designed to let you log in using biometrics, like your fingerprint or face scan, or even hardware tokens, without ever typing out a password. The goal? Make things safer and smoother by cutting out weak links like easily guessed passwords. But the setup phase? That's where things get interesting, and it's not as contradictory as it seems.
Why the Initial Account and Password Step Isn't Going Away
Think about it this way: when you're creating a fresh account on a site or app, the system needs a reliable way to identify you from the get-go. That's where your email or username comes in—it's like your unique address in the online universe. Without it, how would the service know who you are or send you recovery info if something goes wrong? Now, tossing in a password during this creation might feel outdated, but it's often there as a safety net. Not every device supports passkeys yet, and some folks might need a fallback for older browsers or when they're on a shared computer.
- Identity Verification: Services use your email to confirm you're real and to handle things like two-factor checks.
- Recovery Options: If you lose access to your passkey device, that initial password can be a lifesaver for getting back in.
- Backward Compatibility: Not all platforms are fully passkey-ready, so blending old and new methods ensures everyone can join in.
How This Plays Out in Real Scenarios
Picture signing up for a new banking app. You pick an email, set a temporary password, and then the app prompts you to create a passkey. That first password might stick around for emergencies, but once your passkey is active, you can wave goodbye to typing it in daily. It's all about building a secure foundation before going fully hands-off. For more on the tech behind this, check out the WebAuthn Guide—it's a solid resource for geeking out on the details.
And if you're curious about implementing this yourself, here's a quick code snippet to illustrate a basic passkey flow:
title: [TIL] Why the Passkeys process still requires an account and password when creating an account?
published: false
date: 2022-12-09 00:00:00 UTC
tags:
canonical_url: http://www.evanlin.com/til-why-passkeys-need-idpw/
---
# Background:
I wrote an article about [Passkeys after WWDC](https://www.evanlin.com/til-apple-passkeys/). As a result, I saw an interesting tweet a few days ago, which made me re-examine how familiar I am? What are the differences in the actual Passkeys process (first time and subsequent times)? This article will summarize this part.
# (Updated 2022/12/10) If it's the first time creating an account, how many steps are required? Why?
The tweet I saw before mentioned why [Yubico/java-webauthn-server has nearly 21 steps](https://github.com/Yubico/java-webauthn-server#architecture)? This also made me curious to check the original meaning of the related process:
(Pic from [https://github.com/Yubico/java-webauthn-server#architecture](https://github.com/Yubico/java-webauthn-server#architecture))
According to the diagram of this component, everyone will be very curious. Here, you need to combine it with another diagram to see:
- **Step: 1 ~ 4:**
- When creating an account, because it needs to support older browsing devices (browsers/OS), you still need an account and password here. The entire process is the same as the previous database, but the following process is a bit different.
- If there is a User-Agent that supports Passkeys and doesn't need Backward Compatibility, you actually don't need 1 ~ 4 (but you should have them).
- **Step: 5:**
- This is based on the [PKCE method](https://www.evanlin.com/go-oauth-pkce/) to generate a Challenge, which is a value that has been AES encrypted.
- **Step 6 ~ 9:**
- At this time, you can generate a credential ID (optional) and return it to the client side as the value generated by the client agent.
- User-Agent may pass Challenge + credential command + credential ID
- **Step 9 ~ 18:**
- This is where the Client Agent will be activated to open the Passkeys support login process.
- The encrypted credential is transmitted to the server side through private encryption.
- After decrypting with the Public key that was accessed before, confirm whether it is the same credential ID.
- **Step 18 ~ 21:**
- Registration is completed after Auth is completed.
### Several key points are:
- The related process is definitely more cumbersome than the original ID/PW (may be more selective of devices).
- But after the first registration is completed, if the device allows it, you don't need to enter ID / PW afterwards.
- The demo example also uses Passkeys from the first time, but this often cannot be used universally for older devices.
# Passkeys Login Experience
# Support for related devices
(From: [https://www.passkeys.io/](https://www.passkeys.io/))
Here you can see that the WebAuthn called inside Passkeys is actually related to the App and OS version of the browser. So if you want to fully implement the Passkeys system as soon as possible, it is actually the browser support. If it is natively supported by a system similar to Apple, it can also be implemented in the development of the App as soon as possible.
# Finally
(From: [WWDC22 Session: Meet passkeys](https://developer.apple.com/videos/play/wwdc2022/10092/) )
As in the end of this video, Passkeys is not about saving the entire login process. Instead, it is about enhancing the security and user convenience of the entire login process. In order to achieve the true Password-less realm, it actually requires the cooperation of many industries:
- The server side needs to use WebAythn to write its own login application.
- And keep the versions of the related servers up to date
- Also remind users to use the latest version of the phone (seems simpler).
# Reference
- [Apple Doc: Supporting Passkeys](https://developer.apple.com/documentation/authenticationservices/public-private_key_authentication/supporting_passkeys)
- [WWDC22 Session: Meet passkeys](https://developer.apple.com/videos/play/wwdc2022/10092/)
- [WWDC21 Session: Move beyond passwords](https://developer.apple.com/videos/play/wwdc2021/10106/)
- [FIDO2: Web Authentication (WebAuthn)](https://fidoalliance.org/fido2-2/fido2-web-authentication-webauthn/)
- [Passkeys for web authentication](https://www.hanko.io/blog/passkeys-part-1)
- [What Apple’s WWDC Passkeys Announcement Means for Enterprise IAM](https://blog.hypr.com/what-apples-wwdc-passkeys-announcement-means-for-enterprise-iam)
- [https://github.com/duo-labs/webauthn](https://github.com/duo-labs/webauthn)
- [WebAuthn.io: A demo of the WebAuthn specification](https://webauthn.io/)
- [What is WebAuthn? How to Authenticate Users Without a Password](https://www.freecodecamp.org/news/intro-to-webauthn/)
Looking Ahead: The Evolution of Secure Logins
As more devices and browsers catch up, we might see setups that skip passwords entirely, relying solely on passkeys from the jump. But for now, this hybrid approach keeps things practical and secure. It's like training wheels on a bike—you need them at first to build confidence before zooming off freely. Got questions or want to share your experiences with passkeys? Drop a comment below!