标签：#auth

In today's mobile-first world, users expect authentication to be both secure and effortless. Typing passwords every time an app is opened not only impacts the user experience but also introduces security risks if passwords are weak or reused. Biometric authentication solves this problem by allowing users to verify their identity using Fingerprint , Face ID , Touch ID , Iris Scanner , or even their device's PIN/Password . If you're building a React Native application, @sbaiahmed1/react-native-biometrics is one of the most comprehensive biometric libraries available. Beyond simple authentication prompts, it offers hardware-backed cryptographic key management, biometric enrollment detection, device integrity checks, StrongBox support, and compatibility with both the React Native New Architecture and Expo. In this article, we'll explore everything this library offers and learn how to integrate biometric authentication into a React Native application. Why Biometric Authentication? Traditional authentication methods come with several drawbacks: Passwords are easy to forget. Weak passwords are vulnerable to attacks. OTP-based logins can be slow and frustrating. Users often abandon apps with poor login experiences. Biometric authentication addresses these challenges by providing: 🔒 Enhanced security ⚡ Faster authentication 😊 Better user experience 📱 Native platform support 🔑 Secure fallback using device credentials Whether you're building a banking app, healthcare platform, enterprise application, or e-commerce app, biometric authentication has become an expected feature. Installation Install the package using npm: npm install @ sbaiahmed1 /react-native-biometric s or with Yarn: yarn add @ sbaiahmed1 /react-native-biometric s For iOS: cd ios pod install Platform Configuration Before using biometric authentication, configure the required permissions for both Android and iOS. Android Open your android/app/src/main/AndroidManifest.xml file and add the following permissions: <

When a series of regional outages forced a rethink of a multi-region AWS API, the team discovered that an obstacle to global failover was hiding in plain sight: a pre-flight discovery call baked into every client session years earlier as the only available option. This article describes what it took to remove it, and what the rollout actually cost. By Suresh Gururajan

Auth0’s direction is clear: new extensibility work should be built with Actions, not Rules. Auth0’s docs recommend migrating existing logic step by step, converting pieces of Rule code into Action code, testing in staging, and then rolling out one piece at a time. The platform also highlights that Actions give you modern JavaScript, inline documentation, richer type information, and access to public npm packages. I recently looked at the migration path with one question in mind: how do you move from “old but working” to “clean, testable, future-proof” without breaking login flows? This post is the practical version of that answer. Why Auth0 moved from Rules to Actions Rules were Auth0’s earlier customization layer for authentication flows. Actions are the next-generation extensibility platform, built to replace that model with a more structured developer experience. Auth0 positions Actions as a unified environment with version control, debugging, caching, Node 18 support, and access to millions of npm packages. The biggest shift is not just syntactic. Actions use a modern, promise-based programming model and are organized around triggers such as Post Login. That means you are no longer writing the same kind of callback-style Rule you may have used before; you are moving into a more explicit and modular workflow. The mental model change A Rule usually looks like this: it receives user , context , and callback it runs in a broader authentication pipeline it often mixes business logic with token customization, user metadata updates, and side effects An Action, by contrast, is built around a trigger such as onExecutePostLogin , and it receives an event object plus an api object. Auth0’s migration guide explicitly recommends converting Rule code into Action code in stages rather than copying everything at once. That one change matters because it forces you to separate concerns: what is read from the event what is changed through the API what should happen in this trigger

Cloudflare has recently introduced temporary accounts that let AI agents deploy Cloudflare Workers immediately, without first creating or authenticating with a permanent account. If left unclaimed, the accounts and their deployments expire automatically after 60 minutes. By Renato Losio

The Model Context Protocol team has promoted its Enterprise-Managed Authorisation extension to stable status, adding a centralised way for organisations to control access to MCP servers through their identity provider. The project states the aim is to replace per-server consent prompts with a zero-touch flow in which users sign in once and then access approved servers without further setup. By Matt Saunders

OAuth recovery emails look harmless until you test them the lazy way. A team sends password reset links or recovery codes into one shared mailbox, confirms that something arrived, and marks the job done. From a security view, that test is too weak. It can hide token reuse, wrong-user delivery, or log retention that exposes sensitive account events. For non-production checks, I like using a disposable email address that belongs to one test run. Some teams build that inbox layer themselves, some use tempmailso, but the core principle is the same: isolate the recovery event, inspect it quickly, and delete the evidence you no longer need. That is helpful when Authentication and OAuth changes ship together. Why OAuth recovery emails deserve their own threat model Recovery email tests are not just "did the mail send?" checks. They sit on the edge of account takeover risk, so the message itself matters almost as much as the login flow. A decent threat model for these emails should ask: did the message reach only the intended inbox for this run? does the link or code expire when the product says it does? is the message revealing too much user data in subject lines or previews? can an older token still be used after a new recovery request? do logs or test fixtures keep the recovery secret longer than they should? This is where shared inboxes become dangerous in a subtle way. Even if nobody has bad intent, mixed test data makes it harder to prove which token belonged to which request. The same operational confusion shows up in email change confirmation checks , and it gets worse when the email can restore account access. OWASP recommends testing authentication recovery features with the same care as sign-in and session controls, because weak recovery paths are a common bypass route for stronger primary login defenses: https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html A safer test flow for recovery links and codes The cleanest pattern is one inbox

Table of contents What is OAUTH A trip to OAUTH1.0Ville What is OAUTH2.0 Examples of OAUTH Technology OIDC Hands-on Implementation with Microsoft Entra ID What is OAUTH OAUTH is a technological standard that allows you to authorize one app or service to sign in to another without divulging private information, such as passwords. OAUTH stands for Open-Authorization , not Authentication . Authentication is a process that verifies your identity, although OAUTH involves identity verification, its main purpose is to grant access to connect you with different apps and services without requiring you to create a new account. How Does OAUTH Work OAUTH uses access tokens, and this is what makes OAUTH secure to use. An access token is a piece of data that contains information about the user and the resource the token is intended for. A token will also include specific rules for data sharing . For example, you want to share your photos from Instagram with Kyrier — An intelligent email platform built for professionals who refuse to let their inbox run their day , but you only want Kyrier to access your profile image. Kyrier does not also need to access your direct messages or friends list. Instagram issues an access token to Kyrier to access the data you approve (your profile image in this case) on your behalf. So an access token will only allow Kyrier to access your profile image, not even other photos on your page. There may be rules governing when Kyrier can use the access token, it might be for a single use or for recurring uses, and it always has an expiration date. A trip to OAUTH1.0Ville Welcome to OAuth1.0Ville. Please keep your hands inside the vehicle. This is where OAuth started. It was built only for websites , back when "an app" meant a web page and nothing else. Although it worked, it had a lot of problems: Only three authorization flows (2.0 has six) No real plan for mobile or modern apps A scaling problem it never solved It also makes you cryptographically sign e

Security is not a feature — it is a property of your entire architecture. This guide covers the security practices implemented in production SaaS applications like tanstackship.com : authentication with password hashing and session management, role-based and attribute-based authorization, data encryption at rest and in transit, API security with CSRF and rate limiting, and ongoing monitoring for vulnerabilities. Authentication: The Identity Layer Session vs Token-Based Auth Aspect Session Auth JWT Auth Hybrid (Recommended) Storage Server-side (D1/Redis) Client-side (localStorage) Server + client Expiry Server-managed Self-contained Dual expiry Revocation Immediate Difficult (until expiry) Session invalidation + JWT refresh Scale Database lookups per request Stateless Cached sessions XSS risk Lower (HTTP-only cookie) Higher (JS-accessible) HTTP-only cookie for session Implementation with Better Auth // src/lib/auth.ts — using Better Auth with Drizzle import { betterAuth } from " better-auth " import { drizzleAdapter } from " better-auth/adapters/drizzle " import { createDb } from " ../db " export const auth = betterAuth ({ database : drizzleAdapter ( createDb ( env ), { provider : " sqlite " , }), emailAndPassword : { enabled : true , autoSignIn : true , passwordHash : { algorithm : " argon2 " , // Argon2id — OWASP recommended params : { memoryCost : 19456 , timeCost : 2 , parallelism : 1 , }, }, }, socialProviders : { google : { clientId : env . GOOGLE_CLIENT_ID , clientSecret : env . GOOGLE_CLIENT_SECRET }, github : { clientId : env . GITHUB_CLIENT_ID , clientSecret : env . GITHUB_CLIENT_SECRET }, }, session : { expiresIn : 7 * 24 * 60 * 60 , // 7 days updateAge : 24 * 60 * 60 , // Refresh every 24 hours }, }) Password Security Checklist [ ] Passwords hashed with Argon2id (not bcrypt, not scrypt) [ ] Minimum 8 characters, no arbitrary complexity rules [ ] Rate-limited login attempts (5 per minute per IP) [ ] Email verification required before first login [ ] Sessio

A JWT isn't just JSON you can inspect. It's a live bearer token. Here's a safer way to decode one. A few days ago I was reviewing a bug with a teammate. They wanted to see what was inside an access token, so they copied it into the first JWT decoder Google returned. It wasn't a dummy token. It was a production access token with almost an hour left before it expired. Nobody was trying to do anything risky—it was just the quickest way to inspect a JWT. That's exactly why this keeps happening. The thing people forget A JWT looks like this: header.payload.signature The payload isn't encrypted. It's just Base64URL-encoded JSON. Because of that, people often think: "The payload isn't secret, so the token is probably safe to paste." Those aren't the same thing. The payload may be readable, but the token itself is still your credential . Anyone holding it can usually authenticate as you until it expires. Why online decoders make me nervous Some JWT tools only decode locally in your browser. Others offer things like signature verification, claim validation, or key management. Features like those often require talking to a backend, which means the token gets sent somewhere else. Maybe the site is trustworthy. Maybe it isn't. From the UI alone, you usually can't tell. Even if a decoder claims everything runs client-side, I don't like assuming that's true when I'm holding a production credential. You don't need a website to inspect a JWT Most of the time I'm only interested in the payload anyway. echo " $TOKEN " \ | cut -d '.' -f2 \ | base64 --decode \ | jq Because JWTs use Base64URL encoding, you may need to translate the alphabet and add padding first: decode_jwt () { local payload = $( echo -n " $1 " | cut -d . -f2 | tr '_-' '/+' ) while [ $(( ${# payload } % 4 )) -ne 0 ] ; do payload = " ${ payload } =" done echo " $payload " | base64 --decode | jq } decode_jwt " $TOKEN " That gives you the claims, expiration time, issuer, audience—everything most people open a decoder for.

Every authentication mechanism in use today emerged to address a specific set of constraints the previous one wasn't designed for. This article walks through that chain — not as a list of definitions, but as a sequence of problems and the constraints that shaped each solution. 1. The Problem With Sending Passwords Every Request The earliest widely used approach, HTTP Basic Authentication, is also the simplest to understand. The client sends the username and password, base64-encoded, on every single request: GET /api/data Authorization: Basic dXNlcjpwYXNzd29yZA== Base64 is not encryption — it's just a reversible encoding. Anyone who intercepts this header has the raw credentials. This approach has three structural problems. First, the password is transmitted on every request, which means every request is a new opportunity for it to leak — through logs, proxies, or a compromised network. Second, the server has to validate credentials against the database on every single call, since there's no concept of an established session; that's a database hit for every API request, which doesn't scale. Third, there's no way to limit what the credentials can do or for how long. The password grants full access until it's changed, and changing it is the only way to revoke access — there's no way to invalidate just one client's access without affecting every other client using the same password. 2. Sessions Try to Fix It, But Introduce New Problems The next evolution moved the credential check to a single moment: login. After verifying the password once, the server creates a session, stores it (in memory or a database), and gives the client a session ID, usually via a cookie. Every subsequent request just sends that ID, not the password. The user logs in by submitting their username and password. Browser ───────────────▶ Server Login Request The server validates the credentials. Server ── checks username/password ──▶ Database If the credentials are valid, the server creates a new se

Introduction: Unveiling the Critical Vulnerability The recently identified CVE-2026-8037 vulnerability in Progress Kemp LoadMaster represents a critical threat to enterprise infrastructure. This remote code execution (RCE) flaw, stemming from an uninitialized heap issue , enables pre-authentication exploitation, allowing attackers to bypass initial security barriers without valid credentials. The root cause lies in the failure to initialize dynamically allocated memory regions, creating an exploitable condition where untrusted input can corrupt critical data structures. Attackers leverage this memory corruption to redirect program execution to malicious payloads, achieving full system compromise—from data exfiltration to operational disruption. Technically, the vulnerability arises during the software’s handling of untrusted input. When memory chunks in the heap are allocated but not properly initialized, they retain residual data or undefined states. Attackers exploit this oversight by crafting inputs that overwrite function pointers or control-flow structures, hijacking the program’s execution path. The causal sequence is precise: uninitialized heap → memory corruption → arbitrary code execution → system compromise. The pre-authentication nature of the exploit exacerbates the risk, as attackers require no prior access to execute their payload, rendering perimeter defenses ineffective. The implications are severe for enterprises relying on Kemp LoadMaster for load balancing and application delivery. Unpatched systems are exposed to infiltration, data theft, and ransomware deployment. Beyond the technical failure, CVE-2026-8037 exposes systemic deficiencies: insufficient input validation in software design and inadequate security testing during development. Organizations further amplify risk through delayed patch management , creating a critical window of opportunity for attackers. Immediate remediation is imperative to prevent catastrophic breaches that could under

Sign-in worked flawlessly in dev. Then a real user pasted a real code and got "invalid format" — before the code ever reached Supabase. The credential was fine. My regex was wrong. Here's the one-line assumption that broke auth for every human who wasn't me. I run a Discord-native Company Brain. Teams /save docs and /ask grounded answers; access is gated by a magic-link claim that emails a one-time code. Standard GoTrue OTP flow. The client shows a box, you paste the code, the server verifies it. Boring — which is exactly what auth should be. The bug: a six-digit assumption in a validation guard The claim handler did a cheap client-side sanity check before calling verifyOtp : // The bug. Looks reasonable. Rejects every real code. const OTP = /^ \d{6} $/ ; function normalize ( input : string ): string { const code = input . trim (); if ( ! OTP . test ( code )) throw new Error ( " Enter the 6-digit code from your email. " ); return code ; } Every OTP tutorial uses \d{6} . Every code demo shows six digits. So I typed six digits into the test and it passed. In dev I was generating my own codes and never actually reading the email. Supabase's GoTrue emits an eight-digit code on this project. ^\d{6}$ rejects eight digits outright. The user's perfectly valid credential got thrown out by my own front door with a lie for an error message — "enter the 6-digit code" when the email plainly showed eight. Why it happens: OTP length is a setting, not a constant The length of a GoTrue email OTP is configurable — GOTRUE_MAILER_OTP_LENGTH (Dashboard → Authentication → Email). It defaults to six in many setups and to eight in others depending on when and how the project was provisioned. The number in the tutorial is that author's project setting , not a property of OTPs. Hardcoding 6 couples your client to a server config you don't control and might change. Bump the length for security later and every client silently starts rejecting valid codes. No error in your logs — the rejection

In today's world, security is no longer optional - it's expected. Whether it's a fintech app, a fitness tracker, or an internal company tool, users want fast and secure access without the hassle of remembering passwords. That's exactly where biometric authentication comes in. In this guide, we'll walk through how we implement biometric authentication in a Flutter app , the practical approach we follow in production, and the common mistakes developers often make (and how to avoid them). Why Biometric Authentication? Before jumping into implementation, let's quickly understand why it matters: Faster login experience (no typing passwords) More secure than traditional authentication Native support across Android & iOS Better user trust and retention What We Use in Flutter To implement biometric authentication, we rely on: local_auth package (official Flutter plugin) Native biometric APIs under the hood (Face ID, Touch ID, Fingerprint) Step 1: Add Dependency dependencies : local_auth : ^3.0.1 Then run: flutter pub get Step 2: Platform Setup ✅ Android Setup Inside android/app/src/main/AndroidManifest.xml : <uses-permission android:name= "android.permission.USE_BIOMETRIC" /> Also ensure: <uses-feature android:name= "android.hardware.fingerprint" android:required= "false" /> ✅ iOS Setup Inside ios/Runner/Info.plist : <key> NSFaceIDUsageDescription </key> <string> We use Face ID to authenticate you securely </string> ⚠️ Without this, Face ID will NOT work and your app may crash. Step 3: Implement Biometric Logic Here's how we structure it in production: import 'package:flutter/foundation.dart' ; import 'package:local_auth/local_auth.dart' ; class BiometricService { final LocalAuthentication _auth = LocalAuthentication (); /// Check if device supports biometrics Future < bool > isBiometricAvailable () async { try { final bool canCheckBiometrics = await _auth . canCheckBiometrics ; final bool isDeviceSupported = await _auth . isDeviceSupported (); return canCheckBiometrics &&

What building cross-service RBAC taught me about the difference between a fast check and a correct one VaultPay is a wallet microservice I built on top of AuthShield. Previous parts: Part 1 is here: I Built AuthShield and Immediately Knew It Wasn't Enough Part 2 is here: The Silent Failure I Never Saw Coming: What VaultPay Taught Me About Consistency Under Failure Part 3 is here: I Started With a Blocklist. That Was the Wrong Instinct and VaultPay Taught Me Why. Part 4 is here: I Watched Money Move Twice From the Same Request. That's When I Understood Idempotency. Part 5 is here: I Almost Hashed a Document Number That Needed to Be Read Again When I designed JWT validation for VaultPay, the only thing I was optimising for was speed. Local verification, no network call, decode the token with the shared secret, read the claims, move on. Every request gets this. It's fast - no round trip to AuthShield, no added latency on the hot path. That felt like the obvious right answer for a system processing financial transactions, where every millisecond on the request path matters. Then I asked myself a question I hadn't thought through properly: what happens if an admin gets deactivated in AuthShield right now, this second, while they still have a valid token sitting in their browser? The answer, with pure local validation, is uncomfortable. Nothing happens. The token is still cryptographically valid. The signature checks out. The claims say role: admin . VaultPay has no way of knowing that AuthShield revoked this person's access thirty seconds ago, because VaultPay never asked AuthShield. It just trusted the token. That's the moment dual-mode validation stopped being a performance optimisation and became a correctness requirement. Two Services, No Shared Database VaultPay and AuthShield are separate microservices with separate databases. AuthShield owns user accounts, login, JWT issuance, and role management. VaultPay owns wallets, transactions, KYC, and admin operations on t

A single shared API key is fine right up until a second person uses it. intent-brain — the system, repo qmd-team-intent-kb , renamed to the intent-brain plugin v0.4.0 this day — is a team knowledge base. A Fastify HTTP API sits over a governed memory corpus. In front of that API is an MCP server named teamkb , so a teammate doesn't open a dashboard or learn an endpoint. They ask in Claude Code and get a cited answer back with qmd:// citations. That's the whole pitch: institutional memory you query in the same place you write code. Up to this day it authenticated with one shared TEAMKB_API_KEY . The shared key has two failures that only show up once the tool has more than one user. First, every request looks identical, so the audit log can't say who asked. Second, revoking one person means rotating the key for everyone — there's no per-person handle to drop. Both are structural, not bugs you patch. You fix them by giving each person their own credential. The work closed that gap with three things, in this order: per-user tokens (identity), a server-side write gate (authorization), and a per-read access log (audit). The through-line: the API is the real boundary. The MCP client-side tool gate is UX, not security. And the per-read access log stays separate from the governance audit trail — separate log, not no log. Identity: per-user tokens replace the shared key apps/api/src/auth/token-registry.ts . Each token resolves to a record: { actor, role } , where role is 'admin' | 'member' . The shared key's two failures both dissolve here — every request now carries an actor , and revoking one person is dropping one record, not a team-wide rotation. Tokens come from layered sources, in precedence order: explicit records → a TEAMKB_TOKENS JSON env → a TEAMKB_TOKENS_FILE (default ~/.teamkb/tokens.json ) → the legacy single TEAMKB_API_KEY , which becomes one admin token with actor "shared" for back-compat. Each entry is a bearer token resolved to an identity at request time. Ma

Someone on your leadership team asked a reasonable question: should we adopt passkeys? You searched for answers and found implementation tutorials - WebAuthn server libraries, credential storage schemas, ceremony diagrams. They assume you've already decided. None of that helps you answer the question you were actually asked. This article is a decision guide. The question isn't how to implement passkey login. It's whether you should, when the timing makes sense, and for which users first. Implementation details matter eventually - but they don't belong at the front of the decision. You've seen Apple's demos and Google's Chrome nudges. Your security team may have sent a memo about phishing-resistant authentication. You know the term. What you don't have is a clear way to evaluate whether passkeys fit your product, your users, and your team's capacity to ship and support them. By the end of this article, you'll have scored your app against a readiness checklist, mapped show-stoppers that can block adoption, and drafted a one-page recommendation for leadership. Plain Terms: Passkeys, Passwords, and MFA Before scoring your app, you and stakeholders need to mean the same thing when you say "passkey", "password", and "MFA". Vendor decks use these loosely. A PM might say "passkeys replace passwords" while security means "phishing-resistant credentials". Both can be true. Passwords are shared secrets the user types; your server checks a hash. They leak via breaches and phishing sites. Users forget them, reuse them, and call support. MFA adds a second factor - app push, SMS, hardware key, or biometric. It cuts credential-stuffing and many phishing attacks, but adds friction, lost-device tickets, and cross-platform complexity. Passkeys are cryptographic key pairs on the user's device. The private key never leaves the device or synced passkey manager. Sign-in means unlocking with biometrics or a PIN; your server stores only the public key and verifies a signature. On web, the b

You forwarded the phishing email to the security channel about ninety seconds too late. The laptop is already cooperating with someone else. Your personal access token, the one you minted "just for that one script", is on its way to whatever Discord pays for stolen tokens this week. Now what? For users on GitHub Enterprise, what was previously a clickthrough checklist you complete while your hands shake is now one button. On June 24 the GitHub Changelog announced a self-service credential revocation flow under Settings, Credentials. From that view a user can see counts of every credential they have generated or authorized through SSO, then revoke or delete all of them in a single action. Personal access tokens, SSH keys, OAuth tokens, SSO authorizations: gone together. What actually shipped Containment used to be a manual scavenger hunt. PATs sat under Developer Settings. SSH keys lived one tab over. OAuth apps you forgot you authorized two years ago hid behind a different submenu. SSO was its own world. In practice that meant during an incident you forgot something, and the something you forgot was the credential the attacker actually wanted. The new view collapses that surface onto one screen. Counts on one side, a revoke-or-delete-everything action on the other. Whoever wrote it had clearly pictured the 3am screenshot: a user who has just been told to "rotate everything" and has no idea where "everything" lives. GitHub frames this as a complement to an earlier enterprise-owner capability that lets admins with the "Manage enterprise credentials" permission bulk-revoke across one user or many. So there are now two pairs of hands on the kill switch: the user, and the org. (Whichever one notices first.) Why a pipeline owner should care Because users are the trust boundary you keep pretending is somebody else's problem. A leaked PAT in a CI pipeline is rarely a CI bug. It is a human who pasted the token into a script, then a laptop, then a sync folder, then a backup,

Every Nylas request you make on a user's behalf needs one thing first: their permission. Before you can list a mailbox, send on someone's behalf, or read a calendar, the user has to authorize your application through their provider, and that authorization is what's called a grant. Doing the OAuth dance yourself means registering with Google and Microsoft separately, handling each provider's consent screen, token exchange, and refresh quirks. Hosted OAuth collapses that into one flow that works the same across every provider. This post walks through connecting an account from two angles: the HTTP API your web app uses in production, and the nylas CLI for connecting a test account from the terminal. I work on the CLI, so the terminal commands below are the ones I reach for when I need a grant to develop against. What a grant is A grant is an authenticated connection to a single user's account. When a user authorizes your application, Nylas stores the connection and hands you a grant_id , a stable identifier you pass on every subsequent request to act on that user's email, calendar, or contacts. The grant is the unit of access: one user who connected one mailbox is one grant, and everything you build addresses /v3/grants/{grant_id}/... . Keep two credentials distinct here. Your API key authenticates your application to Nylas and goes in the Authorization header on every request; the grant_id identifies which connected user that request acts on. The API key is yours and stays on your backend, while a grant_id is minted per user when they connect. The grant is also where provider differences disappear. A Gmail grant and a Microsoft grant have different OAuth scopes and token mechanics underneath, but once connected, both are just a grant_id you use the same way. That's the point of hosted OAuth: you run one flow, the user picks their provider, and you get back the same kind of identifier regardless of who hosts the mailbox. Hosted OAuth supports Google, Microsoft, Yahoo,

Every identity migration guide eventually reaches the same paragraph, and it's always a little apologetic: "users will need to reset their passwords." It gets treated like a law of nature. It isn't. It's a choice, usually forced by a tool that didn't want to do the harder thing. The harder thing is verifying your users' existing password hashes in place, so they sign in after the move with exactly the credentials they had before and never notice anything happened. Whether you can do it comes down to one question: can you get the old hashes, and can the new system verify them? Password hashes are more portable than people think A password hash isn't a secret algorithm. bcrypt is bcrypt. A bcrypt hash carries its own cost factor and salt inside the string, so anything that implements bcrypt can verify a hash any other bcrypt system produced. The same is true of the PBKDF2 format ASP.NET Identity uses: documented, versioned, self-describing. If you know what you're holding, you can check a password against it without ever knowing the password. So a migration that preserves logins doesn't need the plaintext (nobody has it) and doesn't need to re-hash everyone up front. It needs to obtain the stored hashes and verify against them on sign-in, upgrading each one to its own format quietly the first time a user logs in. That last part is lazy migration: carry the old hash, verify it once, replace it transparently. Over a few weeks of normal logins your user table re-hashes itself and the legacy formats age out, with zero resets and zero support tickets. The dual-path bit The wrinkle is that different sources hand you different formats, and a good importer verifies both: From self-hosted Duende / ASP.NET Identity: the V3 PBKDF2 hashes (and any legacy bcrypt) verify natively and rehash on first sign-in. This is the easy case, because it's the same scheme the destination already uses. Most teams are surprised it's that clean. From Auth0: bcrypt hashes verify verbatim. The catch

Ory Kratos is an open-source, API-first identity and user management system handling registration, login, recovery, verification, and session management with a self-service UI. This guide deploys Kratos using Docker Compose with PostgreSQL, the self-service UI Node, and Traefik handling automatic HTTPS for the public API. By the end, you'll have Kratos managing identities and sessions for users registering through your domain over HTTPS. Prerequisite: SMTP credentials are required for verification and recovery emails. The admin API stays bound to 127.0.0.1 on purpose — never expose it publicly. Set Up the Directory Structure 1. Create the project directories: $ mkdir -p ~/ory-kratos/ { config,data/postgres } $ cd ~/ory-kratos 2. Create the environment file: $ nano .env DOMAIN = kratos.example.com LETSENCRYPT_EMAIL = admin@example.com KRATOS_VERSION = v26.2.0 POSTGRES_USER = kratos POSTGRES_PASSWORD = EXAMPLE_DB_PASSWORD POSTGRES_DB = kratosdb LOG_LEVEL = info 3. Create the identity schema — defines the user fields (email + name) and how the email maps to login, recovery, and verification: $ nano config/identity.schema.json Use the schema described in the Vultr Docs walkthrough — email is the login identifier with password auth; name is a free-text trait. 4. Create the Kratos configuration — public/admin API URLs, password policy (12-char minimum + HaveIBeenPwned), session lifetimes, self-service flows, SMTP courier: $ nano config/kratos.yml Fill in the full configuration from the source article. Key points to keep consistent with the stack below: Public API listens on the internal port and is fronted by Traefik on ${DOMAIN} . Admin API listens on 127.0.0.1:4434 only — used by tooling on the host. The DSN points at the postgres service ( postgres://kratos:...@postgres:5432/kratosdb?sslmode=disable ). The courier section uses your SMTP provider for verification mail. Deploy with Docker Compose 1. Create the Compose manifest: $ nano docker-compose.yml services : traefi