Loading…
Topic
231 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
Grab’s Passkey adds passwordless authentication to its app to address phishing, keystroke-logging, brute-force, and other security threats associated with passwords plus the friction of OTP-based login. Built on the FIDO standard and implemented through WebAuthn, the flow uses a backend, frontend, and authenticator: the authenticator creates and stores a passkey, while Grab stores the public key and metadata. Registration uses a server-generated challenge and parameters including rp.id, user information, resident-key requirements, and supported public-key algorithms; sign-in returns a credential whose signature is verified against the stored public key. Google Password Manager and iCloud Keychain can sync passkeys across supported devices, and users authenticate with their screen lock rather than entering a password or waiting for an OTP. The implementation is described as faster, smoother, phishing-resistant login with potential savings on third-party authentication and messaging costs, while Grab plans to evaluate web login expansion through adoption, feedback, and usage data.
This article reports practical lessons from two September 2024 JP_Stripes events in Aizuwakamatsu and Sapporo for developing and operating Stripe-integrated services more efficiently and at lower cost. Sandboxes let teams create up to five separate test environments, reproduce payment failures and state transitions through Stripe's API, and use CI-specific workspaces without production access. Stripe Connect examples show how a three-person codoc team launched in nine months by staggering account creation and embedding payout and payment-management interfaces. For fraud prevention, the article recommends Radar or Radar for Teams with webhook automation, including early-fraud-warning events and preemptive cancellation or refunds when dispute fees exceed transaction value. Together, these cases emphasize using managed Stripe capabilities and community-shared implementation experience to reduce testing effort, UI work, and fraud-related costs.
The article examines how applications should store and access product data in simple Stripe integrations as requirements for security, performance, and scalability evolve. It compares using Stripe’s built-in product fields with a separate database, while explaining that publishable API keys cannot retrieve product details and that secret or restricted keys must remain server-side. A web backend or serverless function can proxy requests securely, while CloudFront caching reduces repeated calls and latency but requires an appropriate refresh cadence. For richer metadata, inventory, variants, or custom attributes, the article describes combining DynamoDB with Lambda and Stripe, using Event Destinations or webhooks to synchronize changes and weighing that flexibility against database overhead.
The guide explains how developers can use Stripe for UAE-based e-commerce businesses, following its public debut in the country in April 2021. It covers Stripe Billing for recurring billing, Stripe Connect for marketplaces, Stripe Radar's machine-learning fraud protection, and the platform's support for Apple Pay, Google Pay, and more than 135 currencies including AED, BHD, and KWD. Account setup requires business details, KYC documentation based on entity type, and a linked bank account, with sole proprietors and free zone establishments allowed to use personal accounts under the stated conditions. The Dashboard supports payout and transaction tracking, customer and product management, real-time updates, data exports, tax configuration, and Payment Links, while UAE payouts are described as arriving in AED or USD on a T+5 business-day schedule.
Agentic workflows combine large language models with function calling to turn prompts into sequences of actions, but connecting those actions to financial services requires controlled API access. The Stripe agent toolkit integrates Stripe with Vercel’s AI SDK, LangChain, and CrewAI, supports function-calling LLM providers, and is built on Stripe’s Node.js and Python SDKs. It exposes configurable tools for tasks such as invoicing, creating and sharing payment links, and using Issuing virtual cards with spending limits, authorization checks, and deactivation after purchase. Middleware can record input and completion token counts as billing events for usage-based customer billing. Because agent behavior is non-deterministic, the post recommends test mode, evaluations, restricted keys, limited tool sets, and reduced request and response shapes to improve focus and constrain failures.
Stripe Workbench provides browser-based tools for investigating EMV 3DS authentication and related payment flow behavior in the Stripe dashboard. It lets developers inspect Payment Intent and Charge data, including payment_method_details.card.three_d_secure.authentication_flow and result, to determine whether authentication used a challenge UI and whether it completed successfully. The Inspector also exposes API history and webhook events, while the Events tab can filter historical payment_intent.requires_action events and show their frequency over a selected period. In the Shell tab, stripe trigger payment_intent.requires_action simulates a 3DS-related flow and generates event data without installing additional tools, allowing webhook handling to be tested and investigated from the dashboard.
Okta invites SaaS application builders to Oktane 2024, held at Caesars Forum in Las Vegas from October 15–17, to discuss how identity and user lifecycle platforms can support secure B2B SaaS applications. The announcement frames identity as increasingly complex, with a growing protection surface expected to influence SaaS roadmaps and developer priorities. Attendees can join three breakout sessions, visit the Dev Hub, attend hands-on labs, and connect at a B2B SaaS builders happy hour or the Okta Workflows community meetup. Lab topics include moving Okta app configurations from PowerShell into Terraform, signing users out across apps with one API, and identifying inactive users with Okta Workflows. Some activities require Oktane attendance, while labs have limited, first-come-first-served capacity and the happy hour is invitation-based.
Stripe plugins commonly authenticate merchants’ accounts with unrestricted secret API keys, but those keys grant full access and can expose payment, customer, and subscription operations if mishandled or compromised. The post presents restricted API keys (RAK) and OAuth 2.0 as zero-trust alternatives that apply identity verification and least-privilege permissions to third-party integrations. RAKs let developers define narrowly scoped permissions, while OAuth 2.0 uses Stripe’s interface for tokenized, one-click authorization and lets merchants revoke access without sharing a secret key. For existing plugins, it outlines migration through Stripe Apps, Stripe Connect, or manual RAK setup, and states that Stripe will require RAK or OAuth 2.0 authentication from October 29, 2024, with possible fees for merchants still using full-access keys after June 2025.
Stripe integrations can become difficult to test when an account has only one test mode, because unrelated work can interfere and sensitive configuration must remain protected. The post presents Stripe Sandboxes as separate testing areas and shows a Node.js Express application authenticating with a sandbox secret key stored in a .env environment variable. It creates payment intents through /create-payment-intent and retrieves account details through /account, then uses Jest and supertest to verify the sandbox identity, including the expected display name dev-sandbox. A GitHub Actions workflow injects STRIPE_API_KEY from repository secrets, installs dependencies, and runs tests on pushes to the main branch, while .gitignore excludes environment files. The conclusion is that isolated sandboxes and automated checks reduce test tangles and help prevent calls to the wrong environment.
SMS and voice OTPs remain broadly applicable for identity verification, but the post argues they should eventually be replaced because SIM swapping, phishing, uncontrolled secret-delivery channels, device-linking gaps, and slower logins weaken them. Until then, Okta will require organizations to bring their own telephony provider, using a telephony inline hook to send codes and report outcomes. The implementation can be built in-house, outsourced, or delegated to a managed service, with regional regulations, traffic peaks, reliability, branding, security, and available resources shaping the choice. A hook has three seconds to return success or failure before Okta’s heavily rate-limited failover sends the message; teams must also secure endpoints and API keys, monitor logs, and handle vendor or delivery failures.
Okta’s RSA Conference 2024 presence includes a May 7th session on identity as a defense against breaches and a booth featuring the Shared Signals Framework (SSF) and Universal Logout. Attackers can exploit weak passwords, phishing credentials, and privileged access, while applications may lack the cross-service context needed to identify suspicious account behavior. SSF, developed by the OpenID Foundation, enables software to send and receive signals about user behavior so services can respond according to their threat models. Universal Logout lets administrators and automation end a user’s existing sessions with an identity provider, complementing SSF and intrusion detection tools; Okta’s feature was not yet released. The post points to a build-your-own endpoint, SSF resources, and a pilot program for integrators.
The tutorial builds Universal Logout for an OIDC-enabled SaaS Todo application so enterprise administrators can end suspicious user sessions after account compromise or other detected risk. It explains how to create a /global-token-revocation endpoint, connect it to the Express app, identify a user from the revocation request, and invalidate that user's application session. Initial protection uses an API key, while the updated flow upgrades authorization to OAuth 2.0 Private Key JWT with the Okta JWT Verifier library. The tutorial then exposes the endpoint publicly, configures Okta Admin Console integration, and describes optional OIN submission with Private Key JWT and an email identifier for sub_id. In the test, an admin clears the user's sessions and tokens; the Todo app redirects the user to login when they attempt to add a task, demonstrating Universal Logout works.
This walkthrough builds and deploys a Node.js API with Fastify, covering a public directory endpoint and a JWT-protected profile endpoint backed by Heroku Postgres. It uses Fastify’s plugin architecture, including a custom database plugin that reads DATABASE_URL, creates a PostgreSQL pool, and decorates the server with db.query; @fastify/autoload registers plugins from the plugins directory. Authentication uses a JWT signed with an RSA256 private key, while the public key validates requests, and Fastify Swagger plugins generate an OpenAPI specification and UI that Postman can import as an API client. After local testing, the project seeds 50 database records, configures the RSA public key, and deploys through Heroku CLI commands, where the /directory endpoint returns usernames and the deployed API is shown running.
Okta warns that applications using its embedded Sign-In Widget may encounter Chrome login problems after January 1, 2025, when Google’s temporary exemption allowing third-party cookies ends. The guidance recommends testing with Chrome feature flags and watching for console errors, unexpected reauthentication, or logout during session extension. It presents four migration paths: issue first-party cookies through a custom domain, use the authorization code flow with refresh tokens, configure AuthJS with the offline_access scope, or replace deprecated sessions/me calls with supported OAuth and revocation mechanisms. A custom domain can require CSP updates for externally hosted sign-in resources, while offline_access must be enabled both on the authorization server and in application code. An Okta-provided script offers a temporary exemption through the end of 2024, but it is not a lasting fix.
The post explains how browser phaseouts of third-party cookies can affect Okta authentication patterns and session features. Third-party cookies are issued by other domains and can support cross-site session introspection, federated login-related behavior, and convenience features, but browsers increasingly restrict them because of security and privacy concerns. Most Okta core authentication flows do not require them; however, applications using an Okta session across different top-level domains, customer-hosted sign-in experiences, ADSSO, and certain “remember me” functions may lose session introspection or extension while basic authentication and token return remain possible. The post recommends testing with Chrome’s third-party cookies disabled, using feature flags, and migrating away from these cookies before Google’s stated exemption ends in 2024.
Fly.io built a Macaroons-based security token system after finding its API tokens too powerful for expressing scoped permissions and roles. The design starts with a user-linked, HMAC-signed bearer token and chains caveats through HMAC, while checking every caveat independently so each added restriction can only weaken authorization. It models organizations, apps, machines, and volumes with first-party caveats, and also includes third-party caveats, service-token transformations, machine locking, nonce-based revocation, and expiration handling across customer workloads. The resulting system lets users create roles without changing the platform and supports SSO, plugins, and traceable inter-service authorization, although the author acknowledges extra complexity and awkward ways to express some roles.
Step-up authentication lets an application permit access to non-critical resources with basic authentication while requiring additional authentication for sensitive resources. The post describes how Okta Workforce Identity Cloud supports this pattern across modern OIDC applications and legacy integrations. For OIDC, applications use the /authorize endpoint’s acr_values and max_age parameters to request a mapped higher assurance level for a limited period, or prompt=login to force re-authentication each time. For non-OIDC applications, privileged Factor API operations can issue and verify challenges through a protected middleware layer using an Okta API token, while Okta Access Gateway can enforce step-up through advanced policies. Transactional MFA is presented as an alternative using OIDC CIBA, but the source defers its detailed treatment.
Passwords and SMS one-time passwords are presented as vulnerable authentication methods, while the post explains how FIDO and W3C standards support passwordless, phishing-resistant sign-in. It contrasts passwords, SMS OTP, TOTP, and U2F security keys, then introduces FIDO2, which combines WebAuthn with CTAP2 and asymmetric cryptography. The registration and authentication walkthrough describes the Relying Party, client, server, browser, and authenticator interactions, including device-based PINs and biometrics. Passkeys build on WebAuthn and can work across compatible browsers and devices, with migration within some vendor ecosystems described as an additional convenience. Developers can call navigator.credentials.create and navigator.credentials.get directly or use libraries, while Identity Providers such as Okta can provide FIDO2 support through configuration.
Supabase’s July 2023 update lists product releases, community content, and preparations for Launch Week 8, which was scheduled to begin the following week. The shipped changes include a new Android Kotlin client library, Login with Figma as an OAuth provider, Resend support as a custom SMTP provider, pgsodium 3.1.8, and PostgREST 11.1. A performance benchmark examines pgvector 0.4.0’s strengths and limitations, while noting that work on HNSW had started and was not far away. The update also features a Snowflake natural-language query application built with Python, Streamlit, Open AI, and Supabase Vector, plus tutorials, courses, community projects, and hiring announcements.
This tutorial shows how to build a React Native image-sharing or file-sharing app with Expo SDK49, Supabase Authentication, Expo Router v2, and Supabase Storage. It configures a Supabase project, turns off email confirmation for the tutorial, creates a private files bucket, and adds policies that constrain access to an authenticated user’s own folder. The React Native client stores sessions in AsyncStorage, uses the Image Picker and Expo File System, and initializes Supabase with environment-based URL and public key values. The resulting app supports account creation, sign-in, image selection, listing, download-based display, and deletion; resumable uploads are omitted because the attempted implementation produced files with zero bytes.
The best engineering reads, once a week.
