How MaaS Governance Wraps a Model Endpoint on AKS
A model deployed on AKS is open by default. See how MaaS policies insert Authorino authentication and Limitador rate limits in front of vLLM, so bad keys and over-quota requests stop at the gate.
Loading…
Topic
232 posts about Authentication. Every summary links to the original.
See the idea
A model deployed on AKS is open by default. See how MaaS policies insert Authorino authentication and Limitador rate limits in front of vLLM, so bad keys and over-quota requests stop at the gate.
See how an agent request becomes an allowed or denied tool action through identity context, policy checks, scoped credentials, and an auditable decision trail.
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 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
Auth0 released its official Kotlin Multiplatform SDK for Android and iOS, enabling unified authentication logic in shared common code. Developers write login, logout, token management, and direct API calls once in commonMain using Kotlin suspend functions and a sealed Result type for exhaustive error handling. Native security is maintained through platform-specific implementations: Android uses Keystore-backed DataStore and Custom Tabs, iOS uses Keychain and ASWebAuthenticationSession, with Swift async/await interop via SKIE. The SDK is available on Maven Central as com.auth0.kmp:auth0:1.0.0-beta.1 as a single artifact or separate modules, requiring Kotlin 2.3.21, Android minSdk 24, and iOS 14.0+. It includes a Credentials Manager for token storage and automatic renewal, and supports advanced features including WebAuthn passkeys, DPoP token binding, custom storage, and configurable retry with fixed or exponential backoff.
Notion is requiring a second step of verification for password login to protect against credential reuse from other site breaches, and this change will roll out in stages over the next few months. When users set or change a password, they will be guided to set up two-step verification via an authenticator app or phone number and should save the backup codes provided. Users who already have two-step verification on their password need no action, and those without a password can continue using passkeys, email codes, or SSO. For password-only users without two-step verification, Notion will provide notice and time to set up a second step before turning off password-only login; if they choose not to, another method like an email code can still grant access. Additionally, where Notion can verify that another working method exists, it plans to turn off password login for those unused passwords.
Auth0 released a dedicated SDK for TanStack Start, a full-stack React framework, to replace hand-rolled OIDC flows or adapted SDKs. The SDK provides hooks, components, route guards, server middleware, and server helpers that integrate with TanStack Start’s server functions, middleware, and file-based router. Setup involves installing the package, configuring environment variables for the Auth0 application, creating a server-side Auth0 instance, registering the auth0Middleware in the start file, and wiring the router context and Auth0Provider in the root route. The SDK automatically mounts auth routes for login, callback, logout, profile, and backchannel logout, and supports features like login, logout, protected routes via requireAuth, session reading on the server with getSession, and additional capabilities such as passkeys, organizations, MFA, and API scope checks. The fastest way to try it is the official quickstart, which scaffolds a fresh app and adds the SDK step by step.
ClickHouse Cloud now supports JWT authentication for services running version 26.4 or later, allowing short-lived tokens from OpenID Connect providers such as Okta and Microsoft Entra to replace long-lived passwords. When a client presents a token, ClickHouse verifies its signature and claims, then creates an ephemeral in-memory user with the roles and grants specified in the token. The user disappears after the token’s expiration, removing the need for CREATE USER or DROP USER commands. Roles are managed once in ClickHouse and assigned via token claims; identity and group membership are governed by the provider. The feature also handles definer views by writing persistent shadow users, and it supports RS256 keys from version 26.4 and EC keys from version 26.8.
Kube AuthKit is a lightweight Python library that unifies Kubernetes and OpenShift authentication behind a single API, eliminating conditional code paths across local, pod, notebook, and CI/CD environments. It supports four strategies—kubeconfig, in-cluster, OIDC, and OpenShift OAuth—auto-detected by an AuthFactory that probes environment variables and in-cluster markers in a defined order. The library handles token lifecycle transparently, with in-memory storage by default and optional OS keyring persistence for local development to avoid repeated logins. It provides two OIDC flows: device code for headless environments and authorization code with PKCE for interactive applications, both with automatic token refresh. Kube AuthKit returns a standard Kubernetes Python client ApiClient, ensuring full compatibility with the official library, and is actively maintained by the Open Data Hub community for OpenShift AI environments.
Cloudflare’s Quick Tunnels now support email-based access control via the –allowed-mail flag, requiring no account on either side. The feature addresses the risk of exposing sensitive work, especially as AI coding agents increasingly use tunnels to share previews. Cloudflare Access verifies the visitor’s email with a one-time PIN, while cloudflared on the developer’s machine authorizes the request against a local rule list. The guest list never leaves the developer’s machine, and the tunnel remains accountless and free. The feature was built and shipped by two interns, Hugo Vicente and Alessandro Frigerio.
Auth0’s free tier supports up to 25,000 MAUs for MVPs, but teams must complete seven architecture checks before production launch to avoid blockers. The checks cover Auth0 Organizations for multi-tenancy, Enterprise Connections for SSO, Custom Domains, JIT hash migration, Fine-Grained Authorization, MFA factor progression, and tenant lifecycle management. The free plan caps Organizations at five, Enterprise Connections at one plus unlimited Okta, and MFA at passwordless and passkeys only. Upgrading to B2B Essentials or Professional unlocks unlimited organizations, up to five enterprise connections, and advanced MFA including TOTP, WebAuthn, push, and SMS; Professional also enables Custom Database migration scripts. Teams must add a credit card for Custom Domains, add a secondary admin to prevent tenant deletion after 150 days of inactivity, and note that FGA free trial supports 100 MAUs and 50,000 tuples for prototyping.
Building multi-factor authentication (MFA) in-house is a much larger project than teams expect, requiring authenticator app integration, QR code generation, secure backup recovery codes, and edge cases like lost phones. Auth0 positions its MFA offerings as a way to offload that work so developers can focus on core product features. The company’s paid plans include MFA directly, with Pro MFA covering standard authenticator apps in B2C and B2B Essentials plans. Enterprise MFA adds WebAuthn, push notifications, SMS, and voice, available as an add-on to B2B Essentials or included in Professional tiers. Auth0 argues that using its MFA helps teams pass compliance, unblock enterprise deals, and avoid weeks of building login infrastructure.
Personal devices let employees use Slack, approve requests, and access internal apps, but they combine corporate data with private content that Databricks cannot inspect or control. The proposed mobile security model layers Mobile Device Management (MDM), identity and context-aware authentication, Zero Trust Network Access (ZTNA), and application management. On iOS, Account-Driven User Enrollment creates an encrypted workspace without full device management, while Android Work Profile provides comparable separation; per-app VPN keeps work traffic apart from personal traffic. Access requires strong authentication, a managed device, and a trusted tunnel, with continuous posture checks able to block unhealthy devices. Managed apps, configurations, tenant controls, and sensitivity tiers contain data where supported, while transparency about privacy encourages enrollment and supports mobile apps such as Genie.
Okta will end support for Self-Service Registration, Desktop Single Sign-On using Integrated Windows Authentication (IWA), and Device Trust on Classic Engine on March 5, 2027. After that deadline, the capabilities will be turned off unless organizations upgrade to Okta Identity Engine, and Okta will no longer address related bugs, security vulnerabilities, or broken flows. The migration paths are Profile Enrollment Policy for self-service registration, Agentless Desktop Single Sign-On or Okta FastPass for desktop authentication, and management attestation with Okta Verify for mobile device trust. Identity Engine adds passwordless authentication, device assurance, phishing-resistant multifactor authentication, identity verification, zero-trust capabilities, and a newer policy framework, with the upgrade included at no additional licensing cost. Organizations are advised to assess feature usage, test in non-production, and schedule production migration before the hard deadline.
Auth0 Agent Gateway is announced in beta as a Customer Identity and Access Management (CIAM) control plane for governing product-native, customer-facing AI agents in multi-tenant SaaS applications. It addresses a trust model involving organizations, delegated user access, customer consent, independently owned connected accounts, and cross-tenant data boundaries, rather than workforce-only identity. Positioned between an agent and its tools, the gateway evaluates each call using agent, user, and organization context; it uses Organizations, Agents as Principals, Token Vault, token exchange, tenant logs, and administrative controls. The described capabilities include short-lived agent-only tokens, user-scoped credentials, runtime tool authorization, audit logging with optional SIEM streaming, and an agent kill switch. Auth0 is seeking product and engineering teams to join the beta.
Auth0 Identity Conversion Suite addresses identity friction across the visitor-to-user journey, where forced account creation and complicated checkout are cited as contributors to abandonment. It combines Anonymous Sessions, which uses OAuth 2.0 access tokens to track pre-authentication activity and transfer session data into an authenticated profile, with Experiment Center, which supports controlled authentication-flow tests. Visitors can be assigned to percentage- or segment-based variants, kept in the same variant during their journey, and measured through exposure, success-rate, and time-to-auth events across supported Auth0 surfaces. The Early Access release is available to Enterprise-plan Auth0 customers and is presented as a way to improve personalization, onboarding, guest checkout, and authentication decisions without changing application APIs or code.
The Agentic Arcade’s admin panel adds an admin-only “reset all scores” action to prevent a long-lived or stolen admin session from wiping every player’s history. It combines the arcade-admin role with step-up MFA, requiring a recognized MFA signal and auth_time or iat within five minutes. A shared helper checks amr, acr, or a tenant claim; buildMfaStepUpUrl uses acr_values and can add max_age=0, while mfa.challengeWithPopup() opens MFA before the reset request. A beforeSessionSaved hook preserves claims filtered by the Auth0 Next.js SDK, and the API enforces session, role, and freshness gates before clearing scores; cancelled or blocked popups stop the request.
Auth0 is launching an integration for v0 that lets builders add real authentication to prompt-built applications. v0 can respond to requests for login, protected routes, B2B use cases, enterprise identity providers, or MFA by creating Auth0 resources, configuring connections, and wiring its SDK into generated code. The integration operates within the v0 conversational workflow and builds on Auth0’s native Vercel integration, which syncs tenant configuration and credentials across development, preview, and production environments. This replaces placeholder authentication screens with authenticated sessions, protected access, and Auth0-specific implementation patterns including real session handling and protected routes. It is available in any v0 project today, with setup beginning by installing Auth0 from the project’s Integrations settings.
CIAM has expanded beyond password storage and login-time credential checks as digital experiences include autonomous AI agents and attacks make point-in-time verification less reliable. Modern customer identity is presented as a continuous trust and control layer across web, mobile, messaging, voice, email, and AI interactions, balancing low friction with adaptive risk detection. The architecture separates an identity authority, which owns identity, federation, and authorization, from a trust orchestration layer that evaluates live signals, triggers step-up verification, adapts to mid-session risk, and records decisions. It also must define delegated authority for agents, human approval boundaries, multi-signal decisioning, explainability, consent, and identity resolution. Twilio is described as an adjacent execution layer providing Verify, Lookup, carrier intelligence, device fingerprinting, and passwordless or one-time passcode flows for high-risk moments.
The tutorial shows how to add Google login to a Vite-based React single-page app without implementing OAuth directly, using Auth0’s React SDK and Google social connection. It covers installing @auth0/auth0-react, creating an Auth0 Single Page Web Application, checking RS256 and OIDC Conformant settings, registering callback, logout, and web-origin URLs, and supplying the domain and client ID through Vite environment variables. The React code wraps the app in Auth0Provider, uses useAuth0 for loading and authentication state, and calls loginWithRedirect with connection: 'google-oauth2' to bypass provider selection. For production, it explains replacing Auth0’s shared development keys with Google Cloud credentials whose origin and redirect URI target the Auth0 domain, then storing them in the Auth0 social connection. It also points to route protection with withAuthenticationRequired, API access tokens from getAccessTokenSilently, and exact redirect-URI matching as important follow-on considerations.
Auth0 API Access Policies for Applications control whether an application can obtain an access token for a registered API, separately for user-delegated and client access. The FinFlow example separates a browser application that should reach both APIs from a machine-to-machine Risk Engine restricted to the Payments API. Policies provide three choices—allow_all, require_client_grant, and deny_all—while client grants specify an application's audience and permitted scopes, with the audience determining which API policy is evaluated. The guide shows Dashboard and Management API configuration, including subject_type_authorization settings and grants for user and client access. It also explains that third-party applications still require grants under allow_all, while default third-party grants establish a baseline and per-application grants take precedence for exceptions.
The webinar examines how businesses can use WhatsApp for secure account verification, one-time passcodes, operational alerts, and customer conversations. It presents notification overload, third-party portals, single-use apps, and unbranded sender numbers as reasons critical messages may be ignored, affecting deliveries and transactions. Speakers from Twilio, WhatsApp, and Orbio AI describe a verified, two-way model built around WhatsApp Utility messaging, interactive buttons, logic flows, end-to-end encryption, and visual drag-and-drop automation. Orbio AI's examples include screening candidates, scheduling interviews, reminders, onboarding, and engagement conversations for enterprise clients while the webinar claims improved deliverability, faster user action, reduced manual work, protection against SMS toll fraud, and scalable deployment. It also positions app-based delivery over WiFi and cellular networks as a more reliable alternative.
SMS pumping fraud, also called SMS toll fraud, uses bots and fake phone numbers to trigger automated text messages from public-facing endpoints, leaving businesses to pay for traffic that produces no genuine customers. The attack can target OTP requests, sign-up and lead forms, transactional notifications, marketing campaigns, and chatbot endpoints; it may appear as a sudden spike or as distributed low-volume traffic that accumulates over days or weeks. Suggested detection measures include monitoring traffic by use case and geography, reconciling spend with conversions, examining clustered phone-number patterns, and analyzing incomplete forms. The prevention guidance covers CAPTCHA, behavioral bot detection, rate limits, geographic controls, delayed OTP requests, alternative verification methods, and Twilio products including Verify Fraud Guard, SMS Pumping Protection, and Lookup SMS Pumping Risk Score.
This article shows how to deploy an evaluated NeMo Guardrails configuration on a Red Hat OpenShift AI cluster, continuing a series on local development and dataset-based evaluation. It requires OpenShift AI 3.5 or later and namespace write access, while OpenShift AI 3.2 or newer can be configured to use the 3.5 NeMo Guardrails image through TrustyAI service-operator changes. Deployment uses a ConfigMap for the configuration, a NemoGuardrails custom resource, and an authentication annotation that protects the server route; an empty rails.co file is sufficient when no custom algorithms are defined. The deployed server accepts v1/guardrail/checks requests with a bearer token, and the demonstrated classifier permits a benign prompt, blocks a prompt injection, and rejects an invalid token. The article notes that LLM proxying and LLM-based guardrailing are outside its scope.
The best engineering reads, once a week.