标签：#authentication

OAuth can prove that a request may reach a resource. It does not, by itself, tell an operator the full story of the actor holding the token. That distinction matters once software can plan, call tools, retry, and act across several systems. The question is no longer only, "Is this request authenticated?" It is also: Which agent is acting? Under whose authority? For what purpose? Against which target? What evidence will remain after the action? If your system cannot answer those questions without reading the agent's prompt, it does not yet have an operational identity model. It has a credential. A token is permission, not the whole identity OAuth remains essential infrastructure for agents. The current Model Context Protocol authorization specification builds on OAuth 2.1, Protected Resource Metadata, Client ID Metadata Documents, audience binding, and least-privilege scopes. It also hardens issuer validation, defines step-up authorization, and forbids token passthrough. Those controls answer important questions: Is this token intended for this resource? Which permissions did the user approve? Has the credential expired? Does the resource server accept its audience? But a token is still one artifact inside a larger system. It can carry identity claims, but it does not automatically give that identity a lifecycle, an owner, a purpose, or a useful audit trail. An operational identity is the continuity around the token. It says this is the same agent before, during, and after a credential is issued, and that its authority can be understood and withdrawn. Borrowing a human identity breaks the record The fastest way to get an agent moving is often to lend it a human credential. Copy an API key into the environment. Reuse a browser session. Give it an access token created for an employee. Now the log says a person acted when an agent did. The credential may carry every permission the person has, even though the task needed two. Revoking the agent means revoking the human.

Hi DEV! I was fed up picking up my phone to type a six digit code into the machine I was already sitting at. The desktop authenticators I tried either wanted an account, synced my secrets to their cloud, or both, which rather defeats the point of the thing being under my control. AuthGeek is a TOTP and HOTP authenticator that keeps everything local: Secrets in a local vault, encrypted with Argon2id Add accounts by scanning a QR code off the screen, or paste the secret Encrypted backup and restore, so you are not locked into one machine No account, no sync, no telemetry Why I built it The design brief was one sentence: nothing about my second factor should require somebody else's server. I want to be straight about the trade though. Keeping codes on the same machine you log in from is weaker than a separate phone. If your PC is compromised, both factors are on it. For a lot of threat models that is fine, for some it is not. If it is not, keep using your phone, and I would rather say that than pretend otherwise. Tech stack .NET 8, net8.0 Avalonia for the UI Konscious.Security.Cryptography.Argon2 for the vault key derivation ZXing.Net for QR decoding Argon2id over PBKDF2 because the whole value proposition here is the vault, and memory hard is the right default in 2026. Honest caveat The installer is not code signed yet, so SmartScreen may warn on first run. For a security tool I appreciate that is a worse look than usual. It is on the list. Links Site: https://techygeekshome.info/authgeek/ Source: https://github.com/techygeekshome/AuthGeek Video: https://youtu.be/HtrjpdrUe-g If you spot something wrong in the crypto, please open an issue rather than being polite about it.

Short answer: for a server-rendered learning app, create a short-lived session only after the phone code is verified, keep refresh as a separate state transition, and make recovery a deliberate path rather than an accidental logout loop. The useful design artifact is an auditable session record tied to a learner, device context, and recovery status. I build RAG and agent features in Python, so I tend to move from a notebook test to a production boundary quickly. Authentication deserves a slower handoff. In an edtech app, a learner may lose a phone while a parent, teacher, or school administrator still needs a safe way to recover the account. The browser should receive only an opaque session cookie; the server owns the lifecycle and records why each transition happened. How should server-rendered login handle session creation, refresh, and logout? Treat the four actions as different state changes. Code verification proves possession of a phone channel. Session creation establishes a browser session. Verification checks whether that session is still active. Refresh extends a valid session under a stricter policy. Logout revokes one session, while an account-recovery event may need to revoke every session. That separation makes failure visible. A refresh request must not silently create a new account. A logout request must not be interpreted as proof that the phone number is still controlled. For a school district, the audit trail should answer: which learner was affected, which session changed, what policy allowed it, and when the change took place. The request flow is intentionally plain: The existing login form sends a verified learner identifier and a server-held code-verification result to the application backend. The backend calls the session creation boundary and stores the returned session identifier in a secure, HttpOnly cookie. Each protected request verifies that session before loading learner data. A still-valid session may refresh through the refresh bound

A healthtech signup flow can pass its captcha and still leave a dangerous gap: an account is banned in the profile database while an already-issued session keeps working. That is an access-control incident waiting for a clock to run out. Short answer: model a ban as an auditable profile-state transition, then revoke every session as a separate, explicit lifecycle action. Keep the short-lived access credential and its refresh capability under different risk controls, and make “this device” and “all devices” distinct operations. The incident lesson: a profile flag is not a kill switch The operational constraint is immediate shutdown. When abuse review marks a user as banned, the system must stop new work and invalidate existing access without relying on a browser logout button. I have been paged for missed jobs and duplicate deliveries; the same lesson applies here: a state change is only useful if every consumer observes it. The invariant is simple: every authentication action is a checkable, auditable, recoverable state transition. Signup protection (including captcha verification) is one transition. Session creation, verification, refresh, and revocation are four more. Treating them as one giant “auth request” makes it impossible to answer an audit question such as “which session was active after the ban?” Write the ban first, with an audit record that ties the user to the operator, reason, and request ID. Then issue the global revoke command. The ordering matters because a revoke without a durable profile state can be undone by an automatic refresh; a profile update without revocation leaves the old bearer credential alive until expiry. That sounds obvious. It is often missed. How should profile state updates trigger global session revocation? Use two explicit calls and one transaction boundary in your own service. PATCH /v1/auth/user/update/{user_id} changes the profile state. POST /v1/auth/session/revoke_all_for_user/{user_id} invalidates sessions on every devic

Short answer: For a server-rendered Go login, keep session creation, verification, refresh, and logout under one server-side policy, then make password recovery revoke old sessions and emit an audit trail before it creates a new one. The page reaches on-call as a symptom, not a diagnosis: a learner completes /forgot-password , lands on /login again, and support can't tell whether the old browser session was revoked. The least complex design that survives the audit is an opaque cookie backed by a server-side session record, with recovery tokens kept separate from login sessions. That choice does add a stateful lookup to authenticated requests. It also gives the platform team a place to enforce expiry and revocation without trusting the browser to report its own status. No magic here. The page starts at the end of the audit chain The first alert should describe the user-visible control that failed: password recovery completed, yet session revocation did not complete within the authorization-change SLO. A raw rise in 401 responses isn't enough because it mixes expired cookies, revoked sessions, invalid credentials, and application mistakes into one noisy count. The useful page carries a correlation ID, the affected flow, and the oldest incomplete state transition; it does not carry a password, recovery token, or raw session identifier. Work backward from that page. A defensible event chain is recovery_requested , recovery_credential_verified , password_changed , sessions_revoked , and, when policy permits it, new_session_created . The names are local choices rather than a standard, but their order represents the control being audited: the temporary recovery credential proves only that the password may be changed, while the login session authorizes later requests. Combining those credentials makes expiration and revocation harder to explain, so keep separate hashes, lifetimes, and consume paths. Consider two tabs submitting the same recovery form. Both requests may pass

Short answer: progressive profiling should update the record addressed by an immutable user ID, preserve verified identifiers as identities, and record each accepted change as a separately authorized, auditable state transition; it should never create a replacement user merely because a profile field or recovery address changes. For a healthtech sign-up flow, that rule matters more than collecting every field on day one. A patient may begin with an email and password, then add a display name, recovery method, or other application-owned attributes later. The authentication record answers “who is this?” while the profile answers “what do we currently know about this user?” Combining those questions makes recovery dangerous: a changed email can accidentally become a changed person. What does progressive profile retention actually cost? The useful cost model is not a vendor price table. It is the amount of state the team must retain, reconcile, authorize, and eventually delete. Let U be users, P the mutable profile fields stored per user, and E the accepted profile transitions. Current profile storage grows roughly with U x P ; the audit history grows with E . In a system where profiles change repeatedly, E becomes the dominant retention term. Provider calls and invoices still matter, but they aren't the hard part of explaining a patient's account history to a security reviewer. One current row plus one immutable audit event per accepted transition is a tractable design. The event needs the stable user ID, actor, time, operation, previous version, resulting version, and a correlation or idempotency key. Sensitive values need not be copied wholesale into the event. A field name, classification, and integrity-protected reference may provide the required evidence with less exposure; the exact retention period must come from the organization's legal and compliance analysis, not from a generic authentication recipe. This changes the dominant term by separating operational st

Long-lived GCP service account keys are secrets that must be managed forever, are hard to rotate, and are easy to leak. Scaling Workload Identity Federation to 120+ production projects shows why it changes how machine identity is approached entirely: keys are secrets to manage, federated identities are trust relationships configured once, gated by attribute conditions. By Shijin Nair

Short answer: Retry the transport operation, never the OAuth meaning: keep one durable authorization attempt, accept its callback once, and make every downstream effect replayable from recorded state. For a B2B SaaS account-deletion flow, I would block new sessions before attempting remote cleanup, because deleting data while a surviving session can still act is the more dangerous ordering. That is the architecture decision. It treats a timeout as missing knowledge, not proof of failure. A callback may have committed even when the browser received no response; a token exchange may have reached the other side even when the connection closed; an account deletion may be retried by a worker after its first lease expires. The recovery design must therefore answer a narrow question at each boundary: do we know the operation did not happen, do we know it happened, or is the result still unknown? What must remain true during OAuth failure recovery? The first invariant is that an authorization attempt has one identity independent of any HTTP request. Store an opaque flow identifier, the expected callback state, the account or tenant context, a creation time, an expiry, and a small state machine such as pending , exchanging , succeeded , or failed . Don't let a browser refresh create a second logical attempt merely because it creates a second request. The second invariant is single consumption. An authorization code and its state belong to one attempt; the callback handler must atomically claim that attempt before triggering side effects. A duplicate callback should read the previously recorded outcome and return the same application-level destination. It must not provision the user again, issue another internal session, or append a second audit event that claims a second login. Exactly once is the goal, but HTTP cannot promise it by itself, so I use an exactly-once mindset at the business boundary: an atomic database transition establishes who owns the work, unique constrain

Short answer: use an emailed, single-use reset link as the default for most SaaS login recovery, and add SMS OTP only where users may genuinely lack email access or the product already maintains verified phone numbers. Email is usually the simpler system because the login identifier, recovery destination, and support workflow can remain in one channel. SMS can shorten the interaction, but it adds phone-number lifecycle, message segmentation, regional consent, and delivery-state work. “Cheaper” depends on your traffic and failure rates, so model completed recoveries rather than message sends. This is a recovery decision, not a notification preference. The goal is to return the right person to an account without turning a delayed message, an expired credential, or a recycled phone number into an account takeover or a support queue. I've worked around enough spam filtering, rate limiting, and OTP delivery gaps to treat the channel as one component of that system — never as the system itself. What should a SaaS password recovery flow use: email API or SMS OTP? Start with the account data you can already trust. If every user signs in with an email address and changing that address is a controlled operation, an email reset link creates the smaller data surface. The service generates a high-entropy, single-use token, stores only a protected representation of it, sends a link, and accepts that token once before a short expiry. The browser then moves the user into a password-change session. An SMS OTP flow looks compact on screen, yet the backend has more questions to answer. Was the phone number verified recently? Can the user update it without being signed in? How are country codes normalized? What happens when a number is reassigned? Does the support team have a safe path for a person who lost the device? A six-digit form doesn't make those policy decisions disappear. So the default is straightforward. Choose email first when email is the stable account identifier and rec

Plus: Apple sends out an “unprecedented” number of spyware warnings, Ukraine hits a Russian ecommerce giant with cyber and drone attacks, and more.

If you ship email validation with CakeDC/Users , you eventually hit a question the plugin quietly hands back to you: what should happen when someone registers, never clicks the validation link, and then tries to log in? The honest answer is that CakeDC/Users doesn't decide for you. Out of the box you get a database column, a couple of behaviors, and a set of events — but the experience is yours to assemble. Get it wrong and you land in one of two bad places: a user silently logged in without ever validating, or a user who typed the right password and is told "username or password is incorrect." Neither is what you want. This post walks through why that happens in v16, and a clean way to wire the flow using the events the plugin already dispatches — no core hacks, no schema surgery. One flag, two meanings Everything starts with a single boolean column on the users table: active . When email validation is on, registration creates the account with active = 0 and only flips it to 1 when the user clicks the link in the validation email. You can trace it in BaseTokenBehavior::_updateActive() : // $user['validated'] is a transient flag set to false during register() $emailValidated = $user [ 'validated' ]; if ( ! $emailValidated && $validateEmail ) { $user [ 'active' ] = false ; // registered → inactive + token emailed $user -> updateToken ( $tokenExpiration ); } else { $user [ 'active' ] = true ; // clicked the link → active $user [ 'activation_date' ] = new DateTime (); } Notice there is no separate validated column in the database — $user['validated'] is a transient property used only during registration. The persisted truth is active , and it is doing two jobs at once: "Has this person confirmed their email?" — set by the validation flow. "Is this account enabled?" — the thing an admin toggles to ban or suspend someone. That conflation is the root of everything below. Hold onto it; we'll come back to it. How the finder decides who exists Login in CakeDC/Users runs thro

Passkeys are still safer than passwords. That is the answer, and the research behind the scary headlines says so too. On 3 August 2026, Palo Alto Networks' Unit 42 published three techniques that let malware take over accounts protected by Google-synced passkeys. No fingerprint, no PIN, and no prompt on screen. The coverage that followed skipped the part readers need: exactly who is exposed, and what to change. The real scope is narrow. The fix is cheap. The standard itself is not broken. What Pass-ta-key actually is A passkey is a key pair that replaces a password. The private half stays on your device or in a synced store, and the site only ever sees a signature. Unit 42 named three variants, not four. Several outlets reported a fourth, including 9to5Google . The research describes three ( Unit 42 , 3 August 2026). Pass-ta-key. Malware extracts Chrome's device identity key and uses it to sign a request. No admin rights, no device unlock, no user action. Silver Pass-ta-key. The attacker forces Chrome to re-register the device. They then register their own user-verification key with Google's cloud authenticator. Afterwards they can sign in from their own machine, and the cloud authenticator believes a fingerprint check happened. Golden Pass-ta-key. The attacker pulls the Security Domain Secret out of Chrome's process memory during onboarding. The Security Domain Secret is a 32-byte master key that protects every synced passkey. With it, they all decrypt. This is the variant that turns one infection into a saleable bundle ( BleepingComputer , 3 August 2026). The target is not the passkey file on disk. It is the Google Cloud Authenticator behind Google Password Manager, and the trust it puts in a device that malware is now imitating ( The Hacker News , August 2026). Who is actually affected This is the question the coverage left open. Here it is against the research's own stated scope. Setup Status Chrome on Windows with a TPM, Google Password Manager Affected. This i

The mental model that fixes everything JWT is just a token format . It is not authentication, not a session, and not a database. Once you separate those ideas, most of the pain disappears. A JWT is a JSON object that is signed. That's it. The payload holds claims like sub (subject) and exp (expiration). The signature proves the token wasn't tampered with. What JWT is not Not a session store : You can't revoke a JWT before it expires. If you need revocation, you need a blocklist or short expiry. Not a database : Don't stuff heavy data in the payload. It gets sent on every request. Not a magic bullet : It's a way to pass claims between parties without a shared server-side state. The three flows that matter 1. Access token only Simplest flow: login returns a JWT, client sends it in the Authorization header, server verifies it on every request. // server middleware (Express example) const jwt = require ( ' jsonwebtoken ' ); function auth ( req , res , next ) { const header = req . headers . authorization ; if ( ! header ) return res . status ( 401 ). json ({ error : ' No token ' }); const token = header . split ( ' ' )[ 1 ]; // Bearer <token> try { req . user = jwt . verify ( token , process . env . JWT_SECRET ); next (); } catch ( err ) { res . status ( 401 ). json ({ error : ' Invalid token ' }); } } Works fine for small apps, but every request hits your auth logic and the token can't be invalidated early. 2. Access + refresh token Common pattern for SPAs. Access token lives 15 minutes, refresh token lives 7 days. The refresh token is stored securely (httpOnly cookie) and used only to get a new access token. // issue tokens on login const accessToken = jwt . sign ({ userId }, process . env . JWT_SECRET , { expiresIn : ' 15m ' }); const refreshToken = jwt . sign ({ userId }, process . env . REFRESH_SECRET , { expiresIn : ' 7d ' }); res . json ({ accessToken }); res . cookie ( ' refreshToken ' , refreshToken , { httpOnly : true , secure : true , sameSite : ' strict ' })

Why passkey apps treat Windows differently than other operating systems.

You're debugging a broken SSO login. The identity provider (IdP) redirects back to your app, and somewhere in the request is a big blob called SAMLResponse . You grab it, Base64-decode it, and expect to see clean XML. Sometimes you do. Sometimes you get binary garbage that starts with bytes like 0x78 0x9c and looks nothing like markup. Both outcomes are correct. The difference is which SAML binding the IdP used, and once you know the two encoding chains, SAML debugging stops being guesswork. The two bindings, and their two encodings SAML sends its messages ( SAMLResponse , SAMLRequest ) using one of two HTTP bindings, and they encode the payload differently: HTTP-POST binding — the message rides in a hidden form field that auto-submits via POST. The value is simply: Base64(XML) Decode the Base64 and you get the assertion XML directly. This is the common case for the response coming back from the IdP. HTTP-Redirect binding — the message rides in a URL query string, so it has to be small and URL-safe. The value is: URLEncode( Base64( DEFLATE( XML ) ) ) That's three layers. If you only Base64-decode it, you're staring at the raw output of a DEFLATE compressor — which is exactly the binary garbage people report. This binding is typically used for SAMLRequest (the AuthnRequest your app sends to the IdP) and for Single Logout. Critically, the redirect binding uses raw DEFLATE (RFC 1951) with no zlib header and no checksum . That's the single most common thing people get wrong — they reach for a normal zlib/gzip inflate, it chokes on the missing header, and they conclude the blob is corrupt. It isn't; it just needs a raw inflate. Decoding both in Python import base64 import zlib from urllib.parse import unquote # --- HTTP-POST binding: Base64(XML) --- def decode_post ( saml_response : str ) -> str : return base64 . b64decode ( saml_response ). decode ( " utf-8 " ) # --- HTTP-Redirect binding: URLEncode(Base64(DEFLATE(XML))) --- def decode_redirect ( saml_param : str ) -> s

A hands-on guide to being your own Identity Provider — with Laravel 12 and Passport v13. You will build a Central Portal that acts as an OAuth 2.0 Authorization Server, then wire up child sites ( Site A , Site B , Site C ) so a user logs in once and gets access to all of them. No Google. No Auth0. No Keycloak. No "Sign in with…" anything. You own the users table, you issue the codes and tokens, you hold the signing keys. The only dependency is laravel/passport , which implements the OAuth 2.0 protocol machinery — every identity decision is yours to make, and this guide walks through each one. The scope is deliberately narrow: authentication only. How a user proves who they are at a central server, and how a child site learns that identity. Everything else (admin CRUD screens, audit logging, UI theming) is left out. Everything here is buildable on a fresh Laravel install. No prior context needed. Table of Contents What We Are Building OAuth 2.0 Foundations System Architecture Authentication Workflows Part A — Building the Central Portal Part B — Building a Child Site Registering a Child Site End-to-End Testing Gotchas & Security Notes Reference Tables Appendix A — Extending to Multiple User Types Appendix B — Mental Model in One Page 1. What We Are Building The Problem You operate several web applications. Each has its own users table, its own login form, its own password reset flow. When a staff member joins, someone creates four accounts. When they leave, someone must remember to disable four accounts. Passwords drift out of sync. There is no single place to answer "who has access to what?" The Solution One central server owns identity. Every child site delegates login to it. ┌─────────────────────────────┐ │ Central Portal │ │ ┌───────────────────────┐ │ │ │ admin.portal.test │ │ Management UI │ │ │ │ — create users │ └───────────────────────┘ │ — grant per-site access │ ┌───────────────────────┐ │ │ │ sso.portal.test │ │ OAuth 2.0 endpoints │ │ (authorization ser

This article describes an anonymized enterprise implementation. Company names, internal domains, repository identifiers, ticket numbers, and proprietary control names have been intentionally removed or generalized. Multi-factor authentication is often described as a login problem: enter a password, receive a code, confirm identity. That model was not enough for the system described in this case study. The product ran in an in-store environment where the same tablet could be used by several people during a transaction: an employee initiating the process; a manager approving or supporting it; a customer reviewing and signing on their own device. The challenge was not simply to prove that a user knew a six-digit code. We needed to create a secure, short-lived handoff between a shared in-store session and the customer’s personal phone, without leaking the downstream signing session or allowing multiple devices to claim the same transaction. This post explains the architecture, the security model, the trade-offs, and the production practices behind that platform. The actual problem: secure device handoff The workflow started on a shared tablet. At a certain point, the customer needed to continue part of the process on their own phone. The platform therefore had to answer several questions: How does the phone prove that it belongs to the customer currently standing in front of the employee? How does the shared tablet know that the correct phone claimed the correct session? What happens if the QR code is scanned twice? How do we prevent session identifiers and tokens from appearing in URLs, browser history, logs, or referrer headers? How do we notify the phone immediately when verification succeeds? How do we ensure that a single-use signing URL is never exposed before verification? Those constraints turned a seemingly small MFA feature into a distributed-system problem involving identity, real-time communication, concurrency, edge delivery, infrastructure, and operational

Harrowing story of an identity theft victim. Yes, the person made a mistake—they gave the scammer a two-factor authentication code that allowed the scammer to take over their email address. But the real story here is how, for many of us, the security of most of our accounts hangs on the security of our email accounts.

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