# Passkeys Passkeys are a passwordless authentication technology involving client authentication assertions, server-side challenges, credential options, and cryptographic verification. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## UK.gov begins killing off passwords for 23 million users DevFeed: [UK.gov begins killing off passwords for 23 million users]() Original publisher: [Read original article]() Author: Carly Page Published: 2026-09-14T09:16:11Z Content type: article Language: en Sources: [www.theregister.com - Articles]() Topics: [Passkeys](), [passwords](), [Cybersecurity]() Tags: [government-of-the-united-kingdom](), [password](), [passwords](), [phishing](), [security](), [uk](), [whitehall]() ### AI overview The UK government is beginning to replace passwords with passkeys for 23 million users. The change is intended to reduce phishing problems and save Whitehall approximately GBP 600 per day in SMS costs. ### Source excerpt Passkeys promise fewer phishing headaches - and GBP 600 a day off Whitehall's SMS bill ## AuthKit vs Better Auth for B2B SaaS DevFeed: [AuthKit vs Better Auth for B2B SaaS]() Original publisher: [Read original article]() Author: WorkOS Published: 2026-09-14T00:00:00Z Content type: comparison Language: en Sources: [WorkOS Blog]() Topics: [Software as a service](), [Single sign-on (SSO)](), [Security](), [log management](), [threat detection](), [Frameworks](), [MFA](), [Passkeys]() Tags: [auth](), [comparison](), [enterprise](), [logs](), [mfa](), [saas](), [security](), [threat-detection](), [vercel]() ### AI overview This comparison examines AuthKit and Better Auth as platforms for B2B SaaS products selling to enterprise IT buyers. It argues that both now provide core capabilities such as SSO, SCIM, and audit logs, so the meaningful differences are provider coverage, where user lifecycle management begins, and contractual responsibility. The article also describes Better Auth's hosted infrastructure, dashboard, SIEM drain, self-service provisioning, and threat detection features, while noting its convergence with AuthKit on enterprise requirements. ### Source excerpt Both ship SSO, SCIM and audit logs now. The comparison that decides enterprise deals has moved to the long tail: provider coverage, where user lifecycle actually starts, and who is contractually on the hook. ## How WhatsApp Implemented Passkey Authentication for Faster, Phishing-Resistant Sign-In DevFeed: [How WhatsApp Implemented Passkey Authentication for Faster, Phishing-Resistant Sign-In]() Original publisher: [Read original article]() Author: Android Developers (noreply@blogger.com) Published: 2026-08-27T17:00:00Z Content type: article Language: en Sources: [Android Developers Blog]() Topics: [Passkeys](), [Authentication](), [Security, Privacy and Abuse Prevention](), [Cryptography](), [Android]() Tags: [api](), [authentication](), [credential-theft](), [cryptography](), [developer](), [google](), [meta](), [sign-in](), [whatsapp]() ### AI overview The article describes how WhatsApp implemented passkey-based authentication to provide faster sign-ins and reduce phishing and credential-theft risks. It explains the use of public-private key cryptography, biometric or screen-lock authentication, and Android's Credential Manager API. ### Source excerpt Posted by Niharika Arora, Senior Developer Relations Engineer, Tracy Agyemang, Product Marketing Manager, Google and Mayank Manuja, Android Engineer, Meta WhatsApp is the world's largest messaging platform, serving billions of users globally. It is the default communication tool for people across diverse regions, connecting users through private, reliable, and secure messaging. "What excites me most is the sheer scale of WhatsApp's impact. Even a small improvement to WhatsApp touches billions of users worldwide," says Mayank Manuja, an Android Engineer on the WhatsApp Registration and Access team who led the design and implementation of passkey-based authentication for WhatsApp. Building for an audience of this magnitude requires navigating a vast range of network conditions, device capabilities, and levels of digital literacy. Recognizing the potential early, WhatsApp committed to adopting passkeys in 2023, becoming one of the first major consumer apps to integrate the technology. By implementing passkeys, WhatsApp aimed to provide a fast, phishing-resistant option that significantly reduces user friction while providing robust protection against account takeovers and credential theft. A user creating a passkey on WhatsApp for faster, more secure sign-ins. The Decision to Adopt Passkeys For WhatsApp, offering multiple access methods is key to making it easier for users to stay connected and regain access when needed. Passkeys offer users a streamlined, one-tap login experience that eliminates phishing risks and functions reliably even in regions where OTP message delivery can be inconsistent. Underneath, passkeys leverage public-private key cryptography to replace manual entry with biometric or screen lock authentication. This workflow drastically improves sign-in speeds by reducing the process to a single tap via a unified, bottom-sheet interface that keeps users engaged within the app's context. The benefits are twofold: passkeys offer users a streamlined login e ## How WhatsApp Upgraded to Secure, Seamless Sign-In for 1 Billion Users with Passkeys DevFeed: [How WhatsApp Upgraded to Secure, Seamless Sign-In for 1 Billion Users with Passkeys]() Original publisher: [Read original article]() Author: Android Developers (noreply@blogger.com) Published: 2026-08-27T17:00:00Z Content type: article Language: en Sources: [Android Developers Blog](), [Android Developers Blog]() Topics: [Passkeys](), [Authentication](), [Security, Privacy and Abuse Prevention](), [Cryptography](), [Android](), [App](), [API]() Tags: [android](), [api](), [app](), [authentication](), [credential-theft](), [cryptography](), [phishing](), [scale](), [whatsapp]() ### AI overview WhatsApp's adoption of passkeys provides a fast, phishing-resistant sign-in method for its large global user base. The article explains how passkeys use public-private key cryptography with biometric or screen-lock authentication, reduce reliance on inconsistent SMS OTP delivery, and simplify implementation through Android's Credential Manager API. ### Source excerpt Posted by Niharika Arora, Senior Developer Relations Engineer, Tracy Agyemang, Product Marketing Manager, Google and Mayank Manuja, Android Engineer, Meta WhatsApp is the world's largest messaging platform, serving billions of users globally. It is the default communication tool for people across diverse regions, connecting users through private, reliable, and secure messaging. "What excites me most is the sheer scale of WhatsApp's impact. Even a small improvement to WhatsApp touches billions of users worldwide," says Mayank Manuja, an Android Engineer on the WhatsApp Registration and Access team who led the design and implementation of passkey-based authentication for WhatsApp. Building for an audience of this magnitude requires navigating a vast range of network conditions, device capabilities, and levels of digital literacy. Recognizing the potential early, WhatsApp committed to adopting passkeys in 2023, becoming one of the first major consumer apps to integrate the technology. By implementing passkeys, WhatsApp aimed to provide a fast, phishing-resistant option that significantly reduces user friction while providing robust protection against account takeovers and credential theft. A user creating a passkey on WhatsApp for faster, more secure sign-ins. The Decision to Adopt Passkeys For WhatsApp, offering multiple access methods is key to making it easier for users to stay connected and regain access when needed. Passkeys offer users a streamlined, one-tap login experience that eliminates phishing risks and functions reliably even in regions where OTP message delivery can be inconsistent. Underneath, passkeys leverage public-private key cryptography to replace manual entry with biometric or screen lock authentication. This workflow drastically improves sign-in speeds by reducing the process to a single tap via a unified, bottom-sheet interface that keeps users engaged within the app's context. The benefits are twofold: passkeys offer users a streamlined login e ## 1Password product enhancements: Smarter autofill, phishing prevention, and more DevFeed: [1Password product enhancements: Smarter autofill, phishing prevention, and more]() Original publisher: [Read original article]() Author: info@1password.com (Elaine Atwell) Published: 2026-08-27T00:00:00Z Content type: article Language: en Sources: [Blog on 1Password Blog]() Topics: [1Password in the browser](), [passwords](), [Authentication](), [Passkeys](), [macOS](), [iOS](), [iphone](), [OpenID connect (OIDC)](), [migration](), [Software as a service]() Tags: [authentication](), [ios](), [iphone](), [macos](), [migration](), [news](), [oidc](), [passwords](), [product](), [saas](), [update]() ### AI overview This English developer article presents recent 1Password product enhancements focused on smoother credential management and sign-in. It covers universal sign-in for personal and business accounts, macOS autofill, native password generation and saving in iOS 26.2, an iOS autofill health check, and improvements related to data ownership and migration. ### Source excerpt At 1Password, we're constantly working to make life simpler and more secure for our users, from the biggest businesses to each individual who signs up for our password manager. Over the past few months, we've been rolling out a slew of updates designed to make a difference for customers, whether you're using us at home, at work, or (ideally) both. Here are some of the latest developments for you to explore. Upgrades to autofill and autosave One of the most immediate benefits of using 1Password in your daily life is a smooth experience of creating, saving, and inputting your credentials and logins. These updates help you get the most out of that experience, with fewer clicks, on the devices you already use. Universal sign-in for personal and business accounts Signing in just got simpler with a smarter, modern experience using a one-click prompt. Now in beta, 1Password seamlessly logs you into any site or service at the right moment using your desired authentication method (passwords, passkeys, social sign in, OIDC, SAML*). We remove all the extra steps so you sign in quickly and smoothly, while staying secure. *SAML is only available for business accounts that also have 1Password SaaS Manager. macOS autofill 1Password now works as a native Credential Provider on macOS, so your logins and passkeys easily fill right inside Safari and other desktop apps. Save and generate passwords in iOS 26.2 The password creation experience on iPhone and iPad should happen at the exact moment you need it, especially when you're signing up for a new account. With this update, 1Password shows up natively in Safari and other iOS-native apps so you can generate and save a strong password right in the account creation flow, without leaving what you're doing. This makes it easier to capture credentials when they're created and keeps account setup uninterrupted. Autofill health check for iOS The reliability of iOS autofill depends on a tangle of systems, and when there's a problem with one, ## Roadmap decisions rather than dates. DevFeed: [Roadmap decisions rather than dates.]() Original publisher: [Read original article]() Published: 2026-08-11T14:00:00Z Content type: opinion Language: en Sources: [Will Larson - Irrational Exuberance]() Topics: [Development](), [Passkeys](), [resiliency](), [User Experience](), [Mobile](), [Web]() Tags: [development](), [experience](), [implementation](), [mobile](), [phishing](), [resiliency](), [web]() ### AI overview The article argues that product roadmaps should prioritize decisions and execution constraints rather than fixed dates. It uses the development and rollout of passkey support at Imprint as an example, describing implementation behind a feature flag, staged web release, feedback iteration, and expansion to native mobile experiences. ### Source excerpt One thing that bothered me about Imprint's product after joining was our lack of passkey support. Passkey support is a rare opportunity to increase resiliency to phishing attacks while simultaneously reducing login friction. If it's good for our members, our partners, and our product, it felt like something we should have already shipped. Nonetheless, it was hard to get it onto the roadmap alongside everything else we were working on. To dig into passkeys, I started sketching out the implementation as a side quest. Some iterations later, I had something implemented behind a disabled feature flag for team review. At that point, most problems had a concrete solution implemented, and the remaining issues were messy intersections between passkey implementation and user experience. Issues remained, but the tangible implementation made tradeoffs explicit, and we were able to work through them. Soon thereafter, we launched passkeys to a small group in our web experience, iterated on feedback, finalized the details, and brought those details forward to our native mobile experiences as well. It never got onto the roadmap, but it did ship. Our passkey release planted a seed for me, but it required another experience to fully germinate. We had a discussion about hitting a date for a product extension we're developing. Our conversation kept anchoring on the idea that pulling in a date was dependent on pushing out dates for other projects. Presenting two conflicting projects as requiring timeline tradeoffs wouldn't have caused me to blink an eye five years ago, but in this conversation it inspired a sort of instinctual revolt: with modern development techniques, I believe very few projects are essentially constrained by execution bandwidth. Some are constrained by approvals, others are constrained by cross-team and cross-functional handoffs, and many are constrained by missing decisions, but almost none should be constrained purely on time. Shifting blocks of time across project ## Passkeys in B2B: the real risk is recovery DevFeed: [Passkeys in B2B: the real risk is recovery]() Original publisher: [Read original article]() Author: WorkOS Published: 2026-08-06T15:29:33Z Content type: article Language: en Sources: [WorkOS Blog]() Topics: [Passkeys](), [WebAuthn](), [Cloud](), [systems]() Tags: [b2b](), [cloud](), [cryptographic](), [phishing](), [recovery]() ### AI overview The article explains why consumer passkey guidance does not fully apply to B2B systems. Although passkeys are phishing-resistant WebAuthn credentials, synced passkeys may reside in employees' personal cloud accounts, creating enrollment, ownership, recovery, and revocation challenges when devices are lost or employees leave. ### Source excerpt Consumer passkey guidance optimizes for the login. In B2B, the enrollment and recovery story is what decides whether passkeys actually work. Here's the gap. ## Opaque, Interoperable Passkey Records (and a Go API) DevFeed: [Opaque, Interoperable Passkey Records (and a Go API)]() Original publisher: [Read original article]() Author: Filippo Valsorda Published: 2026-07-20T22:33:32Z Content type: article Language: en Sources: [Filippo Valsorda]() Topics: [WebAuthn](), [Passkeys](), [Go Language](), [Security](), [API](), [passwords]() Tags: [api](), [authentication](), [go](), [password](), [security](), [web](), [web-developers]() ### AI overview The article proposes interoperable passkey record encodings for WebAuthn credentials, allowing applications to store records as opaque strings similar to password hashes. It also presents a potential Go API for handling these records. ### Source excerpt Passkey records are an interoperable format for WebAuthn credentials, similar to password hash strings. I propose a potential crypto/passkey Go API based on them. ## Sign in to Pulumi Cloud with Passkeys DevFeed: [Sign in to Pulumi Cloud with Passkeys]() Original publisher: [Read original article]() Author: Devon Grove Published: 2026-07-13T00:00:00Z Content type: release Language: en Sources: [Pulumi]() Topics: [Passkeys](), [WebAuthn](), [Security](), [passwords]() Tags: [bitbucket](), [features](), [gitlab](), [google](), [oauth](), [passwords](), [product](), [product-launches](), [security]() ### AI overview Pulumi Cloud now supports passkeys for users who sign in with an email address and password. Passkeys use device-stored public-key credentials and WebAuthn, while identity-provider sign-in flows remain unchanged. ### Source excerpt Pulumi Cloud now supports passkeys for users who sign in with email and password. Select a button, approve with Touch ID, Face ID, Windows Hello, or your hardware key, and you're signed in. A passkey is a public-key credential stored on your device: your phone, your laptop, a hardware key (YubiKey, Google Titan, etc.), or your password manager can all function as the authenticator. When you sign in, your device authenticates you locally and signs a challenge from Pulumi Cloud with the private key. The private key stays on your device -- Pulumi Cloud never sees or stores it. Passkeys are built on the WebAuthn standard, so they're already supported on every major browser and operating system. Who this is for This release applies to users who sign in to Pulumi Cloud with an email address and password. If you sign in through an identity provider (IdP), such as GitHub OAuth, GitLab, Bitbucket, Google, or your organization's SAML SSO, your existing flow is unchanged. Why passkeys Passwords have always been the weakest link in account security. Since they are shared secrets, they are vulnerable to phishing attacks, and every place you type one is a place that can be impersonated or a data store that can be leaked. Passkeys swap that out for a per-site key pair that lives on your device: Phishing-resistant by design. A passkey is bound to the exact origin it was registered for. A look-alike domain can't trigger your authenticator. Synced across your devices. Apple iCloud Keychain, Google Password Manager, 1Password, Dashlane, Bitwarden: most credential managers now sync passkeys end-to-end-encrypted to every device you've signed in on. Discoverable. Pulumi Cloud doesn't need to know which user you are before you authenticate. Just select "Sign in with a passkey" and your device offers the right credential. Nothing to remember. A passkey lives on your device. There's no string to memorize, and no sensitive credential stored by us. Setting up a passkey The next time you sign i ## AI, OAuth, And Other Platform APIs In The Core DevFeed: [AI, OAuth, And Other Platform APIs In The Core]() Original publisher: [Read original article]() Author: Shai Almog Published: 2026-05-31T00:00:00Z Content type: article Language: en Sources: [CodeName One]() Topics: [Artificial Intelligence](), [OAuth](), [OpenID connect (OIDC)](), [WebAuthn](), [Passkeys](), [Framework](), [API](), [Large Language Model](), [Ollama](), [llama.cpp](), [vllm](), [SQLite]() Tags: [agent-skill](), [ai](), [api](), [authentication](), [function-calling](), [llama-cpp](), [llm](), [oauth](), [oidc](), [ollama](), [sqlite](), [streaming](), [vllm]() ### AI overview This follow-up release article describes platform APIs moved into the framework core, including a first-class LLM client and ChatView, OAuth and OIDC authentication, WebAuthn passkeys, WiFi and connectivity APIs, and share-sheet callbacks. It also outlines streaming chat, tool calls, embeddings, image generation, and local-model support through Ollama-compatible endpoints. ### Source excerpt Deeper AI integration in the framework core, modern authentication via OAuth / OIDC and WebAuthn passkeys driven from the system browser, and a few smaller additions alongside. ## Passkeys: How They Address Password Defects and Their Limitations DevFeed: [Passkeys: How They Address Password Defects and Their Limitations]() Original publisher: [Read original article]() Author: Dan Lew Published: 2026-05-21T13:29:09Z Content type: tutorial Language: en Sources: [Dan Lew Blog]() Topics: [Passkeys](), [Authentication](), [passwords](), [Authorization]() Tags: [authentication](), [passwords](), [talk]() ### AI overview A writeup of a Minnebar 20 talk explaining passkeys in the context of password history. It distinguishes authentication from authorization and examines password deficiencies, how passkeys address them, and passkeys' own problems. ### Source excerpt This is a writeup of a talk I gave at Minnebar 20. Originally, I threw in some Matrix references to make the talk more fun & engaging. Those jokes work better in person, so I've mostly omitted the Matrix from this writeup (though some vestiges remain). It seems ## Import, autofill, organize: What's new in 1Password this quarter DevFeed: [Import, autofill, organize: What's new in 1Password this quarter]() Original publisher: [Read original article]() Author: info@1password.com (Evan Sandhu) Published: 2026-05-05T00:00:00Z Content type: release Language: en Sources: [Blog on 1Password Blog]() Topics: [passwords](), [migration](), [Protocol (disambiguation)](), [Passkeys](), [Android](), [iOS]() Tags: [android](), [how-to](), [ios](), [migration](), [news](), [passwords](), [release](), [updates]() ### AI overview 1Password's latest release adds direct credential transfer through the Credential Exchange Protocol, Android Autofill health checks, and improved login item creation. The updates aim to simplify migration, mobile setup, and everyday password management. ### Source excerpt A password manager should make everyday tasks feel simple. Whether that's: Saving a new password Signing in on your phone Finding the right item Moving your data from another password manager We've made a set of updates across 1Password in our latest release to improve exactly these moments. Let's get into it! A direct way to move your credentials into 1Password Switching password managers hasn't always felt straightforward. Exporting sensitive data into files, moving them yourself, and importing them again adds friction and risk. We're improving that with a direct credential transfer. This work is part of the Credential Exchange Protocol (CXP), an industry effort to make credential migration more secure and interoperable. We helped author the FIDO Alliance's Credential Exchange Format (CXF), a proposed standard that defines how credentials like passwords, passkeys, and other sensitive data can be structured and transferred safely between providers. For you, this means a simpler experience on both iOS and Android, letting you move your credentials into 1Password without relying on manual export and import, and eliminating the need to handle sensitive files yourself. Get your Autofill setup working smoothly on Android Currently, Autofill on Android depends on several system settings, and when something isn't configured correctly, it's not always clear what the problem is or how to fix it. So we've made this easier. 1Password now brings those settings into one place and checks them for you. You can see at a glance if something isn't set up correctly, like Autofill not being enabled, the wrong service selected, or a required permission turned off. For each issue, 1Password explains what's wrong and takes you directly to the right Android setting so you can fix it. You can also see a simple summary of your setup, so you know whether everything is working as expected or if something needs attention. All of this can be found on the home screen of 1Password by navigating t ## Introducing Advanced Account Security DevFeed: [Introducing Advanced Account Security]() Original publisher: [Read original article]() Published: 2026-04-30T00:00:00Z Content type: article Language: en Sources: [OpenAI News]() Topics: [Security](), [ChatGPT](), [account takeover](), [codex](), [Passkeys](), [Cybersecurity](), [passwords]() Tags: [account-takeover](), [attacks](), [chatgpt](), [codex](), [data](), [phishing](), [privacy](), [product](), [recovery](), [security]() ### AI overview OpenAI introduces Advanced Account Security, an opt-in setting for ChatGPT accounts that also protects Codex through the same login. It combines stronger sign-in requirements, tighter account recovery, reduced exposure from compromised sessions, and greater visibility into account activity. The setting requires passkeys or physical security keys, disables password-based login and email or SMS recovery, and supports backup passkeys, security keys, and recovery keys. ### Source excerpt Introducing Advanced Account Security: phishing-resistant login, stronger recovery, and enhanced protections to safeguard sensitive data and prevent account takeover. ## How Multi-Factor Authentication Helps Keep Your Discord Account Safe DevFeed: [How Multi-Factor Authentication Helps Keep Your Discord Account Safe]() Original publisher: [Read original article]() Author: Locke Published: 2026-03-27T00:00:00Z Content type: tutorial Language: en Sources: [Discord Blog]() Topics: [MFA](), [Discord](), [Authentication](), [Passkeys](), [Security](), [QR Code]() Tags: [authentication](), [blog](), [discord](), [how-to](), [security]() ### AI overview This Discord blog post explains how multi-factor authentication, passkeys, authenticator apps, SMS backup authentication, and QR code login can help protect Discord accounts from account takeover. ### Source excerpt A Discord account is more than just your username and avatar. That's why it's important to help keep your account safe and secure by using Multi-Factor Authentication, SMS Backup Authentication & QR Code Login. Learn how to keep your account more secure in the following blog post! ## Keycloak 26.4.0 released DevFeed: [Keycloak 26.4.0 released]() Original publisher: [Read original article]() Author: Keycloak Team Published: 2025-09-30T00:00:00Z Content type: release Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [Passkeys](), [Security](), [OAuth 2.0](), [Specifications](), [SPIFFE](), [Kubernetes](), [OpenID connect (OIDC)](), [REST API](), [Availability]() Tags: [authentication](), [idm](), [kerberos](), [keycloak](), [keycloak-release](), [kubernetes](), [ldap](), [oauth](), [oauth-2-0](), [oidc](), [openid-connect](), [release](), [rest-api](), [saml](), [security](), [specifications](), [spiffe](), [sso](), [version]() ### AI overview Keycloak 26.4.0 introduces passkeys, federated client authentication using SPIFFE or Kubernetes service account tokens, support for final FAPI 2.0 specifications, and full DPoP support. The release also includes availability and administration improvements. ### Source excerpt To download the release go to Keycloak downloads. Highlights This release features new capabilities focused on security enhancements, deeper integration, and improved server administration. The highlights of this release are: Passkeys for seamless, passwordless authentication of users. Federated Client Authentication to use SPIFFE or Kubernetes service account tokens for client authentication. Simplified deployments across multiple availability zones to boost availability. FAPI 2 Final: Keycloak now supports the final specifications of FAPI 2.0 Security Profile and FAPI 2.0 Message Signing. DPoP: The OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP) is now fully supported. Improvements include the ability to bind only refresh tokens for public clients, and securing all Keycloak endpoints with DPoP tokens. Read on to learn more about each new feature. If you are upgrading from a previous release, review also the changes listed in the upgrading guide. Security and Standards Passkeys integration (supported) Passkeys are now seamlessly integrated in the Keycloak login forms using both conditional and modal UIs. To activate the integration in the realm, go to Authentication, Policies, Webauthn Passwordless Policy and switch Enable Passkeys to enabled. For more information, see Passkeys. FAPI 2 Final (supported) Keycloak has support for the latest versions of FAPI 2 specifications. Specifications FAPI 2.0 Security Profile and FAPI 2.0 Message Signing are already promoted to Final and Keycloak supports them. Keycloak client policies support the final versions and corresponding client profiles for FAPI 2 are passing the FAPI conformance test suite. Apart from some very minor polishing of existing policies, Keycloak has new client profiles (fapi-2-dpop-security-profile and fapi-2-dpop-message-signing) for the clients that use DPoP and are intended to be FAPI 2 compliant. Thank you to Takashi Norimatsu for contributing this. For more details, see the ## Passkeys support in upcoming Keycloak release (26.4) DevFeed: [Passkeys support in upcoming Keycloak release (26.4)]() Original publisher: [Read original article]() Author: Peter Skopek Published: 2025-09-16T00:00:00Z Content type: release Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [Passkeys](), [Authentication](), [WebAuthn]() Tags: [authentication](), [idm](), [kerberos](), [keycloak](), [keycloak-release](), [ldap](), [openid-connect](), [password](), [release](), [saml](), [sso]() ### AI overview Keycloak 26.4.0 is announced as adding official passkey support. The feature uses conditional and modal UI, is disabled by default, and can be enabled through the WebAuthn Passwordless Policy. A new conditional credential authenticator can skip 2FA when a passkey was used as the primary credential. ### Source excerpt Passkeys have been available in Keycloak since version 23.0.0 as a preview feature. We are happy to announce official support for passkeys in upcoming Keycloak 26.4.0. What is passkey? Definition from FIDO Alliance A passkey is a FIDO authentication credential based on FIDO standards, that allows a user to sign in to apps and websites with the same process that they use to unlock their device (biometrics, PIN, or pattern). Passkeys are FIDO cryptographic credentials that are tied to a user's account on a website or application. More info What's new? Passkeys are now seamlessly integrated to Keycloak using both conditional and modal UI. There is no need to modify default browser flow to use passkeys. Passkeys support is not enabled by default. It needs to be enabled in the WebAuthn Passwordless Policy (Authentication -> Policies -> Webauthn Passwordless Policy). There is new Conditional - credential authenticator that checks if a specific credential type (passkey) has been used during the authentication process. It is added to the default browser flow to skip 2FA in case a passkey was used to log in as the primary credential. Further quite hidden passkey support is also in the re-authentication form, where users can choose passkey as well as password. For more information check Keycloak Server Administration Guide. A few examples Let's start form the fresh Keycloak database. The first steps are obvious ones. create admin user create one test user enable passkey support in (Authentication -> Policies -> Webauthn Passwordless Policy) set default required action in (Authentication -> Required actions -> Webauthn Register Passwordless) (This step is not necessary, one can use Account Console to register a passkey.) No need for any other changes. Conditional UI Conditional UI is displayed when other components of the platform supports this UI style and username input field is present. It can be achieved for example on Linux using Google Chrome browser and 1password password man ## Keycloak 26.3.0 released DevFeed: [Keycloak 26.3.0 released]() Original publisher: [Read original article]() Author: Keycloak Team Published: 2025-07-03T00:00:00Z Content type: release Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [releases](), [Authentication](), [Logging](), [Passkeys](), [WebAuthn](), [migration](), [OAuth 2.0](), [openid](), [Latency]() Tags: [authentication](), [idm](), [kerberos](), [keycloak](), [keycloak-release](), [latency](), [ldap](), [logging](), [migration](), [new-feature](), [oauth-2-0](), [openid-connect](), [otp](), [release](), [releases](), [saml](), [sso]() ### AI overview Keycloak 26.3.0 is a software release that adds supported 2FA recovery codes, simplifies WebAuthn and Passkeys registration and account linking, expands OAuth 2.0 and OpenID Connect connectivity, improves logging throughput and latency, and introduces experimental rolling updates for patch releases. ### Source excerpt To download the release go to Keycloak downloads. Highlights This release delivers advancements to optimize your system and improve the experience of users, developers and administrators: Account recovery with 2FA recovery codes, protecting users from lockout. Simplified experiences for application developers with streamlined WebAuthn/Passkey registration and simplified account linking to identity providers via application initiated actions. Broader connectivity with the ability to broker with any OAuth 2.0 compliant authorization server, and enhanced trusted email verification for OpenID Connect providers. Asynchronous logging for higher throughput and lower latency, ensuring more efficient deployments. For administrators, experimental rolling updates for patch releases mean minimized downtime and smoother upgrades. Read on to learn more about each new feature, and find additional details in the upgrading guide if you are upgrading from a previous release of Keycloak. Recovering your account if you lose your 2FA credentials When using for example a one-time-password (OTP) generators as a second factor for authenticating users (2FA), a user can get locked out of their account when they, for example, lose their phone that contains the OTP generator. To prepare for such a case, the recovery codes feature allows users to print a set of recovery codes as an additional second factor. If the recovery codes are then allowed as an alternative 2FA in the login flow, they can be used instead of the OTP generated passwords. With this release, the recovery codes feature is promoted from preview to a supported feature. For newly created realms, the browser flow now includes the Recovery Authentication Code Form as Disabled, and it can be switched to Alternative by admins if they want to use this feature. For more information about this 2FA method, see the Recovery Codes chapter in the Server Administration Guide. Performance improvements to import, export and migration The time ## Pectra Mainnet Announcement DevFeed: [Pectra Mainnet Announcement]() Original publisher: [Read original article]() Author: EF Protocol Support Published: 2025-04-23T00:00:00Z Content type: release Language: en Sources: [Ethereum Foundation Blog]() Topics: [Ethereum](), [releases](), [Transactions](), [Authentication](), [Passkeys](), [Security]() Tags: [2025](), [abstraction](), [authentication](), [batching](), [ethereum](), [protocol-announcements](), [releases](), [security](), [upgrade]() ### AI overview The Pectra network upgrade is scheduled to activate on Ethereum mainnet on May 7, 2025. The article explains how EIP-7702 adds smart contract capabilities to externally owned accounts and outlines related safety mechanisms. ### Source excerpt The Pectra network upgrade is scheduled to activate on the Ethereum mainnet on May 07, 2025 at epoch 364032 (10:05:11 UTC)! Mainnet client releases are listed below.... ## A Tour of WebAuthn DevFeed: [A Tour of WebAuthn]() Original publisher: [Read original article]() Author: Adam Langley Published: 2024-12-23T00:00:00Z Content type: article Language: en Sources: [ImperialViolet]() Topics: [WebAuthn](), [Passkeys]() Tags: [conference](), [html]() ### AI overview The author announces that a longer work about understanding and using WebAuthn is now available online in HTML. The work expands on earlier posts about WebAuthn and passkeys and was previously distributed as a printed booklet at a FIDO conference. ### Source excerpt I've done a bunch of posts about WebAuthn/passkeys over time. This year I decided to flesh them out a bit into a longer work on understanding and using WebAuthn. If you were at the FIDO conference in Carlsbad this year, you may have received a physical, printed booklet of the result. It took a while to get around to converting to HTML, but the text is now available online. ## Keycloak 26.0.2 released DevFeed: [Keycloak 26.0.2 released]() Original publisher: [Read original article]() Author: Keycloak Team Published: 2024-10-24T00:00:00Z Content type: release Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [JavaScript](), [OpenID connect (OIDC)](), [OpenAPI Specification](), [OpenTelemetry](), [Passkeys](), [WebAuthn](), [Security]() Tags: [ci](), [idm](), [javascript](), [kerberos](), [keycloak](), [keycloak-release](), [ldap](), [migration-guide](), [oidc](), [openapi](), [openid-connect](), [opentelemetry](), [quarkus](), [release](), [saml](), [security](), [sso]() ### AI overview Keycloak 26.0.2 is a maintenance release published on October 24, 2024. It includes an enhancement for trusted certificate configuration and resolves bugs affecting JavaScript adapters, GUI validation, the Organization API documentation, passkeys, OpenTelemetry initialization, organization features, imports, password validation, CLI handling, and other areas. ### Source excerpt To download the release go to Keycloak downloads. Upgrading Before upgrading refer to the migration guide for a complete list of changes. All resolved issues Enhancements #32110 [Documentation] - Configuring trusted certificates - Fully specify truststore path dist/quarkus Bugs #15635 oidc - JavaScript-Adapter LocalStorage#clearExpired does not clear all possible items adapter/javascript #19101 Uncaught (in promise): QuotaExceededError adapter/javascript #20287 When using `oidcProvider` config url (.well-known) it's not possible to use `silentCheckSsoRedirectUri` adapter/javascript #28978 some GUI validation check missing admin/ui #30832 Organization API not available from OpenAPI documentation admin/api #31724 Logout not working after removing Identity Provider of user identity-brokering #33072 Passkeys: Infinite (re-)loading loop on browsers with WebAuthn Conditional UI disabled authentication/webauthn #33844 Wrong documentation link in keycloak-js readme docs #33902 Not persisted config settings prevent server start dist/quarkus #33948 [PERF] OpenTelemetry is initialized even when disabled #33968 Not possible to close dialog boxes when clicking buttons or the close icon admin/ui #33991 Doc CI - broken links error docs #34009 grammatical error in "Managing Organizations" documentation docs #34015 Home URL for security-admin-console is broken admin/ui #34028 Custom keycloak login theme styles.css return error 404 login/ui #34049 Org Invite: `linkExpiration` template variable represents 54 years in minutes organizations #34063 Respect the locale set to a user when redering verify email pages user-profile #34069 Do not show domain match message in the identity-first login when no login hint is provided organizations #34075 Flaky test: org.keycloak.testsuite.broker.KcOidcBrokerTest#testPostBrokerLoginFlowWithOTP_bruteForceEnabled ci #34095 Keycloak 26.0.0/26.0.1 Import Issue: Multiple Realms Not Imported, Duplicated Realm Imported Instead import-export #34151 JS passw ## Why We Transitioned to Clerk for Authentication DevFeed: [Why We Transitioned to Clerk for Authentication]() Original publisher: [Read original article]() Author: João Gris Published: 2024-08-15T00:00:00Z Content type: article Language: en Sources: [Turso Blog]() Topics: [Authentication](), [Passkeys](), [Single sign-on (SSO)](), [Turso](), [Auth0](), [Authorization](), [Next.js]() Tags: [authentication](), [development](), [mfa](), [next-js](), [security](), [speed](), [sso](), [turso]() ### AI overview Turso explains why it moved from a self-built GitHub authentication system to Clerk. The transition addressed growing needs such as MFA, SSO, additional authentication methods, account management, and support for CLI tokens. ### Source excerpt Learn about how and why we transitioned to Clerk from our own auth system for Turso. ## Recap from KubeCon + CloudNativeCon Europe 2024 DevFeed: [Recap from KubeCon + CloudNativeCon Europe 2024]() Original publisher: [Read original article]() Author: Thomas Darimont Published: 2024-04-15T00:00:00Z Content type: article Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [Cloud Native Ecosystem](), [IAM](), [Kubernetes](), [OAuth 2.0](), [Passkeys](), [Open Policy Agent]() Tags: [cloud-native-ecosystem](), [iam](), [idm](), [kerberos](), [keycloak](), [kubecon](), [kubernetes](), [ldap](), [oauth2](), [open-policy-agent](), [openid](), [openid-connect](), [recap](), [saml](), [security](), [sso]() ### AI overview A recap of Keycloak's presence at KubeCon + CloudNativeCon Europe 2024, covering talks on OAuth2 Token Exchange for microservice API security, Keycloak's use in CERN's IAM infrastructure, federated IAM for Kubernetes with OpenFGA, and recent support for Passkeys, OAuth 2.1, and OpenID for Verifiable Credentials. ### Source excerpt After a packed week of fantastic talks at KubeCon + CloudNativeCon Europe 2024 in Paris, we're delighted to share our impressions with the rest of the Keycloak community. Keycloak and OAuth2 Token Exchange for Microservice API Security The presence of Keycloak in many presentations highlighted its importance in the cloud-native ecosystem. Notably, the talk "OAuth2 Token Exchange for Microservice API Security" by Ahmet Soormally & Letz Yaara on OAuth2 Token Exchange (RFC 8693) underscored its application in microservice security and pinpointed areas for Keycloak's enhancement. Efforts to advance the support for Token Exchange are underway, and community feedback is invaluable. Please join the discussion on the current usage of Token Exchange to help us out. Keycloak and the Secrets of the Universe at CERN A standout moment was learning about Keycloak's role at CERN in the talk "The Hard Life of Securing a Particle Accelerator", as shared by Antonio Nappi and Sebastian Lopienski, emphasizing its contribution to securing the particle accelerator's IAM infrastructure. Keycloak supports research on the nature of the universe. How cool is that :) Keycloak, OpenFGA, and Kubernetes Authorizer Jonathan Whitaker's talk "Federated IAM for Kubernetes with OpenFGA" on federated IAM with OpenFGA showcased innovative approaches for managing access to Kubernetes resources through the combination of Keycloak, OpenFGA and a custom Kubernetes Authorizer Web Hook. In particular, the demonstration of temporarily elevated access to Kubernetes resources was very well received. Keycloak: The Leading Edge of AuthN and AuthZ Last but not least, our session, "The Leading Edge of AuthN and AuthZ by Keycloak", presented by Takashi Norimatsu and Thomas Darimont, introduced the latest Keycloak advancements, including support for Passkeys, OAuth 2.1, and OpenID for Verifiable Credentials (OpenID4VC). As part of our talk, we showed the current support for Passkeys and some integration options with ## Keycloak 23.0.0 released DevFeed: [Keycloak 23.0.0 released]() Original publisher: [Read original article]() Author: Keycloak Team Published: 2023-11-23T00:00:00Z Content type: release Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [OAuth 2.0](), [openid](), [Passkeys](), [WebAuthn](), [Authentication](), [Security]() Tags: [idm](), [improvements](), [interoperability](), [kerberos](), [keycloak](), [keycloak-release](), [ldap](), [oauth](), [oauth-2-0](), [openid](), [openid-connect](), [release](), [saml](), [security](), [sso]() ### AI overview Keycloak 23.0.0 adds support for FAPI 2 draft client profiles, previews DPoP and Passkeys, expands introspection endpoint flexibility, adds a feature flag for the OAuth 2.0 device authorization grant, and improves WebAuthn interoperability. ### Source excerpt To download the release go to Keycloak downloads. Highlights OpenID Connect / OAuth 2.0 FAPI 2 drafts support Keycloak has new client profiles fapi-2-security-profile and fapi-2-message-signing, which ensure Keycloak enforces compliance with the latest FAPI 2 draft specifications when communicating with your clients. Thanks to Takashi Norimatsu for the contribution. DPoP preview support Keycloak has preview for support for OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP). Thanks to Takashi Norimatsu and Dmitry Telegin for their contributions. More flexibility for introspection endpoint In previous versions, introspection endpoint automatically returned most claims, which were available in the access token. Now there is new switch Add to token introspection on most of protocol mappers. This addition allows more flexibility as introspection endpoint can return different claims than access token. This is first step towards "Lightweight access tokens" support as access tokens can omit lots of the claims, which would be still returned by the introspection endpoint. When migrating from previous versions, the introspection endpoint should return same claims, which are returned from access token, so the behavior should be effectively the same by default after the migration. Thanks to Shigeyuki Kabano for the contribution. Feature flag for OAuth 2.0 device authorization grant flow The OAuth 2.0 device authorization grant flow now includes a feature flag, so you can easily disable this feature. This feature is still enabled by default. Thanks to Thomas Darimont for the contribution. Authentication Passkeys support Keycloak has preview support for Passkeys. Passkey registration and authentication are realized by the features of WebAuthn. Therefore, users of Keycloak can do passkey registration and authentication by existing WebAuthn registration and authentication. Both synced passkeys and device-bound passkeys can be used for both Same-Device and Cr ## Chrome support for passkeys in iCloud Keychain DevFeed: [Chrome support for passkeys in iCloud Keychain]() Original publisher: [Read original article]() Author: Adam Langley Published: 2023-10-18T00:00:00Z Content type: release Language: en Sources: [ImperialViolet]() Topics: [Chrome](), [Passkeys](), [WebAuthn](), [macOS](), [iOS](), [Google]() Tags: [browsers](), [chrome](), [ios](), [macos](), [settings](), [stable-channel](), [sync](), [terminal]() ### AI overview Chrome 118 adds support for creating and accessing passkeys in iCloud Keychain on macOS 13.5 or later. The article explains the required permission for autofill and account-picker access, as well as iCloud account and sync requirements. ### Source excerpt Chrome 118 (which is rolling out to the Stable channel now) contains support for creating and accessing passkeys in iCloud Keychain. Firstly, I'd like to thank Apple for creating an API for this that browsers can use: it's a bunch of work, and they didn't have to. Chrome has long had support for creating WebAuthn credentials on macOS that were protected by the macOS Keychain and stored in the local Chrome profile. If you've used WebAuthn in Chrome and it asked you for Touch ID (or your unlock password) then it was this. It has worked great for a long time. But passkeys are supposed to be durable, and something that's forever trapped in a local profile on disk is not durable. Also, if you're a macOS + iOS user then it's very convenient to have passkeys sync between your different devices, but Google Password Manager doesn't cover passkeys on those platforms yet. (We're working on it.) So having iCloud Keychain support is hopefully useful for a number of people. With Chrome 118 you'll see an "iCloud Keychain" option appear in Chrome's WebAuthn UI if you're running macOS 13.5 or later: You won't, at first, see iCloud Keychain credentials appear in autofill. That's because you need to grant Chrome permission to access the metadata of iCloud Keychain passkeys before it can display them. So the first time you select iCloud Keychain as an option, you'll see this: If you accept, then iCloud Keychain credentials will appear in autofill, and in Chrome's account picker when you click a button to use passkeys. If you decline, then you won't be asked again. You can still use iCloud Keychain, but you'll have to go though some extra clicks every time. You can change your mind in System Settings -> Passkeys Access for Web Browsers, or you can run tccutil reset WebBrowserPublicKeyCredential from a terminal to reset that permission system wide. (Restart Chrome after doing either of those things.) Saving a passkey in iCloud Keychain requires having an iCloud account and having iCloud K [Next page]()