Authorization Is a Runtime Decision
See how an agent request becomes an allowed or denied tool action through identity context, policy checks, scoped credentials, and an auditable decision trail.
Loading…
Topic
Authentication
228 posts about Authentication. Every summary links to the original.
- 228 posts
- 29 companies
- 5 explainers
See the idea
Authentication explainers
Axum at the Trust Boundary: From Request to Protected Response
Axum is a Rust web framework for composing routes, middleware, and extractors. This explainer shows how different login flows become verified identity before a handler responds.
The Token’s Route: From Auth0 Login to API Authorization
See how an Auth0 login becomes an API decision: redirect the user, issue the right token, validate its claims, and apply audience, scope, and access policies.
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
Newest first
Posts
Coding Agent Horror Stories: The 29 Million Secret Problem
Compromised versions of the Nx npm package, dubbed the s1ngularity campaign, used a post-install hook to repurpose installed AI coding agents as credential scanners. Because AI command-line interfaces often run with the developer's full user permissions, the malware invoked tools such as Claude Code, Gemini CLI, and Amazon Q with permission-bypass flags to map sensitive files. GitGuardian findings indicate that AI-assisted code leaks secrets at roughly twice the baseline rate, largely because models ingest live credentials into working contexts. Docker Sandboxes addresses this risk by restricting the execution environment to the project workspace and keeping actual credentials on the host. When sandboxed with sbx, agents receive sentinel placeholders, while an egress proxy injects real secrets into outgoing network requests.
Build a Flask App with Okta for Secure OIDC Login and Authorized API Calls
Flask web applications require dedicated mechanisms to authenticate users securely and authorize access to downstream services. Developers can address this by integrating Okta as an OpenID Connect identity provider using the Authlib library. Authlib registers Okta as a remote provider and automates the Authorization Code flow using Proof Key for Code Exchange with SHA-256 code challenge verification. After logging in through Okta and completing the callback route, the Flask web application uses the acquired OAuth 2.0 access token to query a protected backend resource server. This architecture ensures that user credentials remain managed by Okta while client requests to backend API endpoints carry valid, scoped authorization tokens.
Securing Infrastructure at Scale: Introducing Pinterest’s Resource Provisioner Pipeline (RPP)
Managing Infrastructure as Code across distributed repositories presents significant security and operational challenges. Pinterest developed the Resource Provisioner Pipeline (RPP), a proprietary Terraform execution engine, to securely deploy and manage AWS infrastructure across hundreds of workspaces. The pipeline utilizes centralized GitHub composite actions triggered by pull request events and enforces dual human approvals. To maintain least privilege, RPP uses GitHub OpenID Connect authentication to assume a central identity before validating repository paths and down-scoping to specific team execution roles. Automated checks include backend state validation, linting, plan generation, Semgrep static analysis, and optional LocalStack testing before deliberate comment-driven deployments execute.
Enable Your SAML Requesting App for Cross App Access
Cross App Access allows enterprise applications federated with Security Assertion Markup Language to interact with third-party resource APIs without migrating to OpenID Connect. The flow adapts the Identity Assertion Authorization Grant specification to SAML by adding three token exchange steps following the standard single sign-on handshake. First, the application exchanges the validated SAML assertion for an OAuth refresh token using Okta's token endpoint and a private key JSON Web Token. The application then uses the refresh token to request a short-lived Identity Assertion Authorization Grant token from Okta. Finally, the application presents the Identity Assertion Authorization Grant token to the third-party authorization server to obtain an OAuth access token.
The New DMARC is Here
DMARCbis is finalized as three Standards Track RFCs: RFC 9989 for the core protocol, RFC 9990 for aggregate reporting, and RFC 9991 for failure reporting. Existing DMARC records continue working as before, so most senders do not need immediate changes. The largest behavioral update replaces Public Suffix List lookups with an algorithmic DNS Tree Walk, in which receivers query _dmarc records up the DNS hierarchy; the psd tag can declare hierarchy boundaries. The pct tag is replaced by boolean t, while np can specify a policy for non-existent subdomains, including np=reject. Reporting knobs rf and ri are removed, but rua and ruf remain available; senders using fractional pct should use a none-to-quarantine-to-reject rollout, keep reading reports, and avoid rushing to reject.
Build a Secure C# MCP App with Cross App Access (XAA)
Cross App Access (XAA) addresses the gap between a user’s authenticated identity and a downstream MCP server, API, or agent tool that must trust that identity without another login. The described flow uses OIDC and PKCE for sign-in, then RFC 8693 token exchange to turn the ID token into a JWT Authorization Grant (JAG), followed by RFC 7523 exchange at the MCP authorization server for a scoped bearer token. A C# MCP SDK IdentityAssertionGrantProvider encapsulates both exchanges, while ASP.NET Core OIDC middleware persists the ID token and an HTTP transport presents the resulting token to the MCP server. The sample connects to a Todo resource through the xaa.dev playground, completes MCP initialization, lists resources, and reads todo0://todos; the article states that the end-to-end implementation fits in under 50 lines of C#.
From Day 1 to Production: Building Lyft’s Analytics & Rides Intelligence Assistant as Onboarding…
Lyft developed Aria, an AI-powered assistant allowing approved employees to query ride analytics via natural language through a backend with LangGraph orchestration and SQL generation. However, Aria's user interface was limited to a Streamlit prototype that lacked standard service framework integration, Lyft authentication, and multi-user scalability. To resolve these limitations, a new engineer built a production-grade web client from scratch using Lyft's internal Node.js framework and Next.js as a three-week onboarding assignment. The implementation involved configuring Envoy routing, resolving authentication plugin incompatibilities, debugging service connectivity with Grafana, and managing interface state with an XState state machine. Aria was successfully hardened and launched into production, expanding natural language analytics access across the company.
Introducing Okta Journeys: A Better Way for Developers to Learn Identity
Okta has introduced Journeys, a task-oriented documentation format designed to streamline how developers learn and implement identity management. Rather than requiring engineers to manually assemble information across disparate guides, articles, and API references, each Journey provides an end-to-end curriculum for a specific project. Content is organized into three distinct phases: foundational knowledge in Learn, architectural decision-making in Plan, and curated implementation steps in Build. The initial release includes six Journeys aimed at Okta Customer Identity builders who are implementing authentication, registration, branding, and user management. Future additions will address AI agent governance, integrations for the Okta Integration Network, and migrations from the Classic Engine to the Okta Identity Engine.
Enabling Cross App Access for SAML-Based Resource Apps
Cross App Access (XAA) lets applications using existing SAML federation obtain API access without migrating to OpenID Connect (OIDC). An agent presents a short-lived Identity Assertion Authorization Grant (ID-JAG), which the resource authorization server validates, resolves to a user, and exchanges for its own access token; SAML processing remains upstream. For SAML identity resolution, implementations must validate the saml-nameid sub_id and match issuer, NameID, and sp_name_qualifier rather than relying on NameID alone. The guide recommends binding iss to a registered SAML connection before verifying the JWT against that connection’s JWKS, then checking typ, aud, and client_id and applying local scope policy. It also walks through Okta configuration and xaa.dev checks that redeem the ID-JAG, call the API, and export conformance results.
Securing Heroku CLI Credentials with System Keychain Storage
Heroku CLI 11.8.0 changes credential storage by making the system keychain the default and retaining .netrc as a fallback. The transition began in 11.6.0, when the CLI stored tokens in both locations to preserve existing workflows. The credential manager uses macOS security, Linux Secret Service through secret-tool, or Windows PasswordVault, storing credentials under “heroku-cli” with the account email as the identifier. Authentication lookup prioritizes HEROKU_API_KEY, then HEROKU_NETRC_WRITE, keychain storage, and .netrc files; unsupported or failing keychain access falls back to .netrc. Version 11.8.0 also adds a Git credential helper, so commands such as git push heroku main continue without configuration changes, while CI/CD can keep using HEROKU_API_KEY and Linux users may need secret-tool.
How to Govern Autonomous Agents in Enterprise AI Factories
Autonomous AI agents require governed environments to safely inspect code, execute tests, query enterprise systems, and handle sensitive business data. The NVIDIA Secure Agent Workspace Reference Design shifts agent execution away from user laptops to dedicated, single-user virtual machines managed on Red Hat OpenShift Virtualization or Microsoft Azure. Perimeter defenses enforce enterprise single sign-on access broker connections, default-deny network egress rules, and human approval gates for critical state-changing actions. Inside the workspace virtual machine, active sandboxing through NVIDIA OpenShell evaluates signed security policies before each tool invocation while credential proxies prevent direct access to raw secrets. GitOps workflows continuously reconcile infrastructure profiles and network configurations while all operational and security telemetry streams to centralized SIEM platforms in OCSF format.
How Verifiable Digital Credentials Are Reshaping Trust Architecture
Verifiable Digital Credentials (VDCs) are presented as a new trust layer for applications that need to verify claims such as age, licenses, employment, or eligibility without collecting documents and excess PII. The model uses an Issuer-Holder-Verifier trust triangle: authorities sign credentials, users hold them in wallets, and applications request specific proofs, with selective disclosure limiting exposed data. The standards stack combines SD-JWT VC or mdoc credential formats, OpenID4VCI for issuance, OpenID4VP for presentation, and the W3C Digital Credentials API for browser-wallet invocation. Production verification also requires issuer trust lists, trust-framework integration, and key rotation, not merely signature checks. Because browser API rollout is still progressing, the recommended baseline is redirect-based OpenID4VP with the Digital Credentials API added as a progressive enhancement, starting with one bounded verification use case.
Palana (Part 2): Architecting isolation, identity, and auditability for AI agents
Palana is Grab’s Kubernetes-native secure execution platform for autonomous AI agents, designed to provide isolated, attributable, and auditable environments. It provisions per-agent namespaces, service accounts, EFS-backed storage, ingress, policies, and proxy-mediated egress, while admission webhooks inject proxy settings and enforce pod restrictions. Human identity remains authoritative for RBAC, while sanitized identifiers are reserved for object names and Vault paths; secrets are split between agent-readable values and proxy-only credentials, and the LLM wrapper derives agent identity from Kubernetes context. Layer 3/4 controls provide containment, Layer 7 OPA-backed proxy policies govern host and method access, and structured signals support audit and idle shutdown that preserves /data and platform state. The production lessons emphasize platform-level controls, a safe self-service path, namespace boundaries, proxy-mediated authentication, and lifecycle management as prerequisites for useful autonomy.
Payment Fraud Detection: How Banks and Businesses Stop Fraudulent Transactions
Payment fraud detection is presented as a real-time practice for identifying and blocking unauthorized transactions amid evolving card-not-present, account takeover, authorised push payment, friendly, and card-testing attacks. Modern systems combine predefined rules, machine learning, behavioral analytics, device fingerprints, geolocation, transaction history, and velocity signals to calculate risk scores within milliseconds, declining or routing high-risk payments to review. Rules are fast and interpretable but require continual tuning, while machine-learning and behavioral models can identify complex or user-specific patterns that static thresholds miss. The source also emphasizes prevention controls such as MFA, tokenization, 3D Secure, and device binding, alongside unified real-time data infrastructure that supports cross-channel signals, continuous retraining, and deployment into payment authorization flows.
AI agents are a confused deputy with the keys to your kingdom
Attackers recently compromised over twenty thousand Instagram accounts by manipulating Meta's AI support assistant to rebind recovery email addresses without verifying account ownership. This incident illustrates the classic confused deputy security problem, where a privileged process is persuaded by an unprivileged user to perform unauthorized operations. Because large language model interfaces operate purely on natural language and cannot distinguish instructions from data, the model itself cannot serve as an authorization boundary. Securing AI agents requires verifying caller identity through external policy checks against authenticated sessions rather than relying on chat context or prompt engineering. Teams must enforce least privilege with short-lived scoped credentials, place irreversible actions behind hard policy gates or human approvals, and maintain audit trails of agent actions.
Enhance Security and Trust: New Session Metadata in Sign in with Google
Sign in with Google now provides verified applications with two OpenID Connect session metadata claims, auth_time and amr, in ID tokens. auth_time records the last successful Google authentication time, distinguishing session freshness from token issuance, while amr is a JSON array identifying authentication methods such as pwd, mfa, hwk, swk, tel, and sms. The claims are available across Android, iOS, and web client and server applications, and can support audit logging, step-up authentication based on session age, and authorization rules requiring stronger methods for sensitive operations. Verified applications request them through the standard OIDC claims parameter without significantly changing an existing Sign in with Google authentication flow.
From hobby to real world: integrating the hard stuff with agents
The post documents building a production-oriented leaderboard for open-source Stripe Projects applications, where users submit projects, share links, and vote. Unlike an earlier transcription app, this project required authentication, multiple database tables, hosting, and controls limiting unauthenticated users to one vote per project. The agent initially selected Supabase for database and auth and Vercel for hosting, then added Upstash Redis after an in-memory rate limiter proved unsuitable for serverless enforcement. Supabase's two-emails-per-hour authentication limit prompted a human-directed migration to Clerk, after the agent proposed an unsuitable Twilio solution. The resulting MVP used five resources across four providers, took more than a day, and received separate security and performance audits before review.
Announcing the Public Preview of Custom URLs
Databricks has announced the public preview of Custom URLs, giving each account a single branded domain that serves its workspaces. Previously, workspace-specific URLs made navigation, sharing, bookmarking, and account-wide features more cumbersome, while users had to log in repeatedly when switching workspaces. Custom URLs use a shared account session to verify access and create workspace sessions seamlessly, while preserving authorization boundaries and keeping existing per-workspace URLs functional. The feature provides a unified Genie entry point, cross-workspace Unity Catalog lineage, and an account-level URL that remains stable during disaster-recovery failover, including for downstream tools using existing connection strings. Activation requires Unified Login; Frontend Private Link workspaces fall back to per-workspace URLs, and account admins can claim a URL, enable it, and optionally turn on automatic redirects.
What's new in clickhousectl v0.3.0
clickhousectl v0.3.0 adds improvements aimed at agentic workflows, additional installation methods, OAuth for Cloud service queries, and custom configuration files for local servers. It detects coding-agent environments and defaults to JSON on stdout, uses gh-style exit codes, reads CLICKHOUSE_ credentials from a working-directory .env file, and hides deprecated API fields from CLI output. Cloud service queries can authenticate with OAuth without provisioning a Query Endpoint; idled services wake automatically, while stopped services fail with a start hint. For local development, selected versions resolve from installed binaries before network lookup, local use can put ClickHouse on PATH, and named XML, YAML, or YML files overlay built-in defaults. The release also adds Python installation options and extends local init with a postgres/ tree alongside clickhouse/.
Introducing ClickStack Cloud: Serverless observability powered by ClickHouse
ClickStack Cloud is entering private preview as a fully managed, serverless observability service built on ClickHouse for teams that want ClickHouse-powered logs, metrics, and traces without operating the underlying infrastructure. Users send OpenTelemetry data to a managed OTLP endpoint, while the service handles ingestion, durable buffering through an object-storage-backed event queue, scaling, storage, and query serving, then exposes telemetry in the ClickStack UI with integrated authentication and RBAC. The preview separates ingestion and query resources and is developing automatic tuning based on query patterns, including materialized fields, primary-key adjustments, materialized views, and indexes. Dedicated query compute for agentic and high-volume analytical workloads is planned after the preview, while pricing remains unfinished and the existing Managed ClickStack offering remains intended for teams requiring direct infrastructure and schema control.
Related topics
All topics →Weekly digest
The best engineering reads, once a week.