标签：#auth

AWS recently introduced Amazon Cognito multi-region replication, which automatically replicates user identities and user pool configurations from a primary region to a secondary one. This enables applications to continue authenticating users from a replica region during outages, without requiring custom replication and failover mechanisms. By Renato Losio

Uber recently described an internal architecture for propagating identity across multi-agent AI workflows. The design aims to perserve user context, agent provenance, and scoped access as agents delegate work and call internal tools. The case study aligns with Auth0’s view that AI agents need permissions based on delegated authority, scoped credentials, and explicit human approval boundaries. By Eran Stiller

Two HNG Tasks That Taught Me More Than the Spec This is my Stage 9B write-up for the HNG internship . No new code just two tasks that stuck: one I owned solo across multiple repos, and one I shipped inside a team product under real deadline pressure. If you've ever had auth work almost done for three days straight, or watched an LLM politely ignore your JSON schema, you'll recognize these stories. Task 1 (Individual): Insighta Labs — One API, Three Clients, One Auth System Stage: 3 (Technical Requirements Document / TRD track) Why I picked it: Auth looked "done" on paper. It wasn't. Web portal, CLI, and graders all needed to log in differently, and every environment (localhost, Railway, preview URLs) found a new way to break. What it was Insighta Labs is a queryable profile-intelligence API I built during HNG. By Stage 3 the backend wasn't just CRUD anymore it needed GitHub OAuth with PKCE , JWT access + refresh with rotation , RBAC ( admin vs analyst ), rate limits, API versioning, and three first-class clients : Client Repo How it authenticates Backend API HNG_STAGE-1 Issues tokens, sets cookies Web portal Insighta-WebPortal HTTP-only cookies + CSRF CLI Insighta-Cli PKCE + local callback + Bearer tokens Every /api/* route required X-API-Version: 1 and a valid session. Access tokens expired in 3 minutes ; refresh tokens in 5 minutes with rotation. That sounds harsh, it was intentional, and it surfaced bugs fast. The problem it was solving Reviewers and real users had to prove identity without sharing one login mechanism. Browsers should never see raw tokens in JavaScript. The CLI can't use cookie redirects the same way a React app does. Automated graders needed a test path that didn't depend on GitHub's OAuth exchange. One auth design. Three runtimes. Zero "works on my machine only." How I approached it I split auth into explicit paths instead of one generic "login" handler: Web flow GET /auth/github — server stores PKCE verifier, redirects to GitHub GET /auth/gith

Connecting to a payment gateway rarely fails because of business logic. More often, it fails at the very first technical step: authentication. If you’ve ever worked with payment APIs, you know the drill. Before sending a single request, you need to generate a cryptographic key pair and sign every request correctly. Sounds straightforward—until you actually try to do it. The hidden hurdle in every integration To securely call the Payneteasy API, each request must be signed. That means: Generating an RSA key pair (usually via OpenSSL) Converting between PKCS#1 and PKCS#8 formats Building a correct signature base string Percent-encoding everything properly Signing with RSA-SHA256 or HMAC-SHA1 Assembling the Authorization header One small mistake—a missing character, wrong encoding, or incorrect format—and your request gets rejected. For teams without deep cryptography expertise, this step alone can turn a one-day integration into a week-long debugging session. If you’re curious, the full manual process is documented here: https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html#generating-key-pair The solution: Key Pair Factory We built the Payneteasy Key Pair Factory to remove this bottleneck entirely. Instead of dealing with OpenSSL commands and key formats, you can generate everything you need in just a few clicks. What it does: Generates a ready-to-use RSA key pair Ensures correct formatting for Payneteasy APIs Eliminates manual conversion and configuration errors Keeps the private key on your side Provides a public key for request verification No cryptography expertise required. The tool is open-source and available on GitHub: https://github.com/payneteasy/key-pair-factory Why this matters This is not just about convenience—it directly impacts integration speed and success. With the Key Pair Factory, you get: Faster onboarding Fewer integration errors Less back-and-forth with support teams A smoother developer experience I

OAuth for Remote MCP Servers How each AI assistant signs in to a remote MCP (Model Context Protocol) server, and why the flow differs by client and by where it runs. Overview The protocol throughout is standard OAuth 2.1 — an open, widely implemented authorization standard. The human sign-in runs through oauth2-proxy , one of the most widely deployed open-source auth proxies; the only deployment-specific piece is a thin, spec-conforming authorization server (the /oauth endpoints) that hands MCP clients their tokens. Every client ends up the same way — a person signs in against Google (restricted to your organization's domain), and the client holds a short-lived bearer token it presents on each /mcp call. Two things differ between assistants: where the client runs (a machine on the VPN — private — vs. the vendor's cloud — public ), which decides the host it reaches; and what kind of OAuth client it is — a public client proving itself with PKCE (Proof Key for Code Exchange, which lets a client with no secret prove the token request comes from the same client that started the flow), or a confidential client proving itself with a secret. The participants oauth2-proxy — the public-facing reverse proxy. It authenticates the human against Google (the sign-in restricted to your organization's domain) and forwards the verified identity to the app behind it. Only oauth2-proxy faces the internet. It is a mature, heavily-deployed open-source project — the standard way to put Google/OIDC (OpenID Connect) single sign-on in front of a service, widely used in Kubernetes deployments — so the most security-sensitive leg of the flow (the OAuth exchange with the identity provider) runs on battle-tested code. The MCP server — the app on a loopback port behind the proxy. It plays two roles: the OAuth authorization server ( /oauth/authorize , /oauth/token , /oauth/register , .well-known discovery) and the /mcp tool endpoint. It mints codes and tokens, and validates a token on every /mcp c

Note: This is an English digest of the original Zenn post (Japanese) . Read there for the full timeline and commit-level trace. TL;DR We ship tasteck , a B2B SaaS for the Japanese night-leisure industry (dispatch + cast shift management). 8 years of operational data, ~100 venues live. Two days after the MCP design post , ChatGPT Plus can call our tools live: "Who's available tonight?" → MCP list_available_drivers → JSON → natural-language reply. Estimated B2 OAuth sprint = 2 weeks (6/16–7/1). Actual = 1 day , by reading the spec carefully before touching code. We hit 12 distinct traps between "OAuth issuance works" and "ChatGPT actually invokes the tool." The QA logs caught every one. What we shipped 3 read tools (B1): list_available_drivers — drivers free tonight list_cast_shifts — today's cast shift roster list_assignable_casts — joined resolution: roster ∧ stage-name set ∧ shop match Natural-language date helper: resolveBusinessDate(naturalText, company) — handles "today / tomorrow / day-after-tomorrow" and the per-tenant business-day boundary (e.g. day flips at 04:00 or 05:00, configured per Company.changeDateTime ). MCP SDK Server + SSE transport: @modelcontextprotocol/sdk wired into a NestJS controller. One SSE connection = one McpServer instance, company-scoped, with a session_id Map routing POST /messages . OAuth flow (B2, finished in one day across 7 steps) Step What Commit 1 Protected Resource Metadata endpoint (RFC 9728) d6f05ff6 2 /authorize + consent screen + PKCE start 107edbcb 3 /token + PKCE verify + JWT issue + resource (RFC 8707) ffd0468c 4 OAuthAccessTokenGuard (RS256 + HS256 fallback, extracts companyId / staffId ) f2c9bed4 5 Streamable HTTP transport (SSE → POST /sse/:companyId for JSON-RPC) 3a28d92f 6 resolveBusinessDate undefined fallback (`(naturalText 7 QA redeploy + ChatGPT live demo — The 12 traps (compressed) The full timeline is in the Japanese post; the abridged list: Discovery path mismatch. ChatGPT expected {% raw %} .well-known/oauth

1. Introduction As the golden standard of secure remote access , the Secure Shell (SSH) protocol has several layers of protection. One of them involves recording and keeping track of the known servers on the client side. known_hosts By default, the known_hosts file for a given user is located at: cat /home/user_name/.ssh/known_hosts github.com ssh-rsa *** github.com ecdsa-sha2-nistp256 *** github.com ssh-ed25519 *** Basically, the file contains a list with several columns, separated by whitespace: Identifying host data Host key type Host key value Optional comment The first column can be hashed or cleartext, depending on the setting of HashKnownHosts in /etc/ssh/ssh_config . When hashed, the first field of each line starts with |1| , a HASH_MAGIC marker. After the latter, the field continues with a random 160-bit string, otherwise known as a salt, followed by a 160-bit SHA1 hash. Each of these is encoded in base64 . The main idea is to hide the IP address or hostname data, which would otherwise be directly visible Either way, known_hosts contains a mapping between a server as identified by its characteristics and its key . ## Known Hosts Checking When connecting to a remote host, SSH checks the known_hosts file of the client to confirm the address or hostname for the server match the key we get from it . If there is a match, the session setup can continue. Otherwise, we get an error. The entry for 192.168.6.66 in the known_hosts file doesn’t match the (Elliptic Curve Digital Signature Algorithm, ECDSA ) key we got back from the server at that address . Critically, if we don’t know what caused the error, we should heed the text in capital letters: something nasty can indeed be happening . On the other hand, the reasons for such an issue can be valid and trivial: dynamic IP address changed hostname reinstalled system reinstalled SSH Docker container misconfigured DHCP relocated client In fact, there can be many more. ## Bypass Known Hosts The error text when connectin