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
229 posts about Authentication. Every summary links to the original.
- 229 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
Secure Authentication with a Push Notification in Your iOS Device
The tutorial shows how to build a native iOS sign-in flow using Okta DirectAuth and push notification MFA. It starts with an Okta Integrator Free Plan org, configures an OIDC Native Application and enables Okta Verify push notifications, while noting additional authorization policies may be required for a custom authorization server. In Xcode, the app uses Swift, SwiftUI, Swift Package Manager, and the Okta mobile Swift packages OktaDirectAuth and AuthFoundation to handle credentials, tokens, and MFA challenges without browser redirects. An AuthService coordinates authentication state, user and token information, sign-out, access-token refresh, and session restoration from stored credentials. The completed flow is described as phishing-resistant and able to maintain an active session directly within a SwiftUI app.
Voice Cloning with Consent
Realistic voice generation presents significant deepfake risks alongside legitimate communication benefits. To prevent unauthorized voice duplication, a voice consent gate integrates verification directly into the voice cloning workflow. The system relies on a language model to generate novel sentence pairs containing explicit consent and phonetically diverse phrases on random everyday topics. Users must read these generated lines aloud through a direct microphone stream rather than uploading pre-recorded files, and an automatic speech recognition system verifies the utterance against the generated text. Once confirmed, the consenting audio snippet is passed directly to the voice-cloning text-to-speech model as the reference sample for synthesis.
Kurt Got Got
Fly.io recounts the takeover of its X/Twitter account after CEO Kurt Mackey entered credentials on members-x.com in response to a phishing email from alerts-x.com. The attackers revoked existing tokens, configured new 2FA, changed the account email, and used it for a crypto scam; the company says no customer systems or accounts were at risk, though the incident caused more than 15 hours of brand damage. Fly.io attributes the exposure to treating the shared social account as a legacy exception rather than protecting it through its normal Google IdP and phishing-resistant MFA. The post explains how FIDO2, U2F, and Passkeys prevent fake sites from receiving real credentials, while noting that the 1Password browser plugin could also have flagged the mismatched domain. The account is now protected with Passkeys.
Charting a New Course for SaaS Security: Why MongoDB Helped Build the SSCF
Widespread enterprise SaaS adoption has introduced notable security blind spots due to inconsistent controls, visibility, and configurations across disparate vendor applications. While traditional compliance frameworks such as SOC 2 and ISO 27001 evaluate provider organizational security, they typically fail to address customer-facing application capabilities. To resolve this discrepancy, MongoDB collaborated with the Cloud Security Alliance and GuidePoint Security to develop the SaaS Security Capability Framework. This framework establishes actionable technical controls across six critical operational domains, including identity and access management, machine-readable logging, configuration management, and incident notifications. By standardizing customer-side capabilities within the shared responsibility model, the framework simplifies vendor risk assessments and provides engineering teams with structured implementation benchmarks.
Introducing the Okta Open Source MCP Server
The Okta Open Source MCP Server connects large language model agents to Okta’s Admin Management APIs for identity and access management workflows. It translates natural-language requests into structured API calls, supporting user and group management, group membership and application operations, system-log retrieval, and additional application and policy actions. The server uses Okta’s official SDK and supports interactive Device Authorization Grant authentication or browserless Private Key JWT, with scoped API access and credentials supplied through environment variables. The guide explains setup with Python 3.9 or later and uv, Okta application configuration, and VS Code’s MCP client settings, then shows examples including user administration and audit-report generation. Its stated purpose is to automate organization-management tasks while respecting Okta’s security model.
How to Build a Secure iOS App with MFA
This tutorial shows how to add secure authentication and backend authorization to an iOS app using Okta’s BrowserSignIn module from the Okta Swift SDK. It registers a native OIDC client with Authorization Code Flow and PKCE, configures redirect URIs and authorization-server policies, and recommends phishing-resistant MFA factors such as Okta Verify with biometrics and FIDO2 with WebAuthn. The implementation uses Swift Package Manager, an Okta.plist configuration file, a testable AuthService protocol, and SwiftUI views for login, token handling, user information, and authenticated state. It then demonstrates authorized API requests by attaching an access token to a URLRequest, calling a backend endpoint, decoding its response, and displaying a returned message, concluding that OAuth 2.0 and JWT validation provide integrated authorization verification.
Guardrails for money movement: Integrating Stripe MCP with Portia AI
Portia AI presents a customer-refund agent that combines its guardrails with Stripe’s official Model Context Protocol server. The agent reads a refund request, compares it with a policy file, identifies the relevant Stripe customer and payment intent, and evaluates whether the request should be approved. Portia’s planner produces a multi-agent plan, while execution agents run it and persist outputs in plan state; an execution hook pauses before the Stripe create-refund call. A clarification presents the request and the agent’s rationale to a human, who can approve it in the CLI; approval allows the refund to proceed, while rejection exits without creating one. The example also handles Gmail OAuth and can send the customer an email describing the outcome.
It's Time to Evolve Authentication Security
Identity-based attacks and compromised credentials are driving a need for stronger authentication, while security requirements must be balanced against user friction and application sensitivity. The guidance recommends phishing-resistant factors, including smart cards, biometric-capable hardware, FIDO2 with WebAuthn, and Passkeys, while warning against security questions, SMS codes, email TOTP, and password antipatterns. It also advises using strong MFA as a backup, dynamic authentication policies and threat detection, and OAuth 2.1/OIDC through an identity provider, with step-up authentication to maintain assurances during a session. For application integration, the recommended approach is to redirect users to an Okta-hosted Sign-In Widget through vetted OIDC client libraries or Okta SDKs, reducing implementation errors in PKCE and token verification while supporting evolving standards.
Introducing CIBA for Secure Transaction Verification
CIBA addresses identity verification when an application cannot use an interactive login on the consumption device, including bank customer-service changes, retail POS payments, browser-constrained devices, and shared kiosks. Client-Initiated Backchannel Authentication decouples authentication from the application: a client sends a back-channel request to an OAuth 2.0 authorization provider, while the user approves it on a separately enrolled phone or smartwatch. CIBA extends OpenID Connect with a grant type, discovery metadata, and poll, ping, and push token-delivery modes; in the described banking flow, the application receives a user-scoped token to update the email address. The approach improves least-privilege access and avoids exposing credentials on shared devices, but can enable MFA-fatigue-style attacks, should not be used same-device, and may warrant device code flow in some cases.
Secure Your Express App with OAuth 2.0, OIDC, and PKCE
Building authentication from scratch is risky and time-consuming, so the tutorial integrates Okta with an Express application using Passport, openid-client, OAuth 2.0, and OpenID Connect (OIDC). It creates a role-based expense dashboard in which users view spending data for their assigned teams, with team membership mapped from the email claim in the ID token. The setup uses Authorization Code Flow with PKCE, defined in RFC 7636, alongside express-session, EJS views, environment variables, and Okta redirect URI configuration. The sample project includes routes for login, logout, dashboard, profile, and team-specific expenses, while the running app displays these authenticated views. It concludes that OIDC supplies the identity layer over OAuth 2.0 and presents PKCE as a security baseline for server-side and browser-based web applications.
Create a React PWA with Social Login Authentication
The tutorial builds a React Progressive Web App (PWA) called Lister, combining offline support with authentication through Okta and Google Social Login. It creates an Okta OIDC single-page application, configures Authorization Code and Refresh Token grants, sets localhost redirect URIs, and wires Okta React and AuthJS into React Router routes. The implementation uses environment variables for the Okta domain and client ID, OAuth 2.0 and OpenID Connect scopes including openid, profile, email, and offline_access, and a Vite PWA plugin to provide a manifest, service worker, and installable behavior. Authenticated users receive a todo-list interface with CRUD operations, while the article notes that production deployments would need more advanced service-worker configuration and a proper database.
Using Connect embedded components to streamline your Connect onboarding flow
Furever, a test Connect platform for pet grooming, needs to onboard connected accounts and keep them compliant and activated while reducing friction. It first creates Custom accounts with card_payments and transfers requested, then contrasts Stripe-hosted account links with an embedded flow built from Account Sessions, loadConnectAndInitialize, and ConnectAccountOnboarding. The integration supports appearance variables for branding, disable_stripe_user_authentication when the platform owns losses and requirement collection, and onStepChange analytics for onboarding progress. A shared connectInstance can also render ConnectPayments, which provides payment listing, refunds, and dispute management without building that interface; the source also notes localization, framework support beyond React, and additional components.
Effortless enterprise authentication at Grab: Dex in action
Grab built Concedo to centralise access management, authentication, and authorisation across internal applications and external platforms. Its customised Google OAuth2.0-based mechanism created integration challenges with systems such as Databricks and Datadog, producing fragmented sign-on experiences and administrative overhead. To standardise identity, the team adopted OpenID Connect (OIDC) and used Dex, a federated OpenID Connect provider that aggregates identity providers and issues standardised OIDC tokens. Dex supports single sign-on, multiple identity providers, token delegation between trusted peer services, and a kill switch that can redirect traffic during an identity provider outage. The implementation separated application authentication concerns and established a single identity source, while a future phase will address fragmented authorisation through a unified model.
Astronomy Geek to Oktanaut: Landing as a Dev Advocate at Okta
Akanksha Bhasin joins Okta as an “Oktanaut” in Developer Relations after more than six years building developer communities and four years focused on Developer Relations. Her path began with experiments in Arduino, programming, and AI applications, then shifted toward Voice AI after Google Assistant launched in 2018; she built applications for Google Assistant and Alexa and was later featured at Google I/O. She taught these technologies at meetups and colleges across India, founded Women in Voice, India, led Google Developer Groups, and helped organize events including DevFests that gathered more than 3,000 developers. At Okta, she wants to help independent software vendors and developers secure user identities, treating identity security and access management as foundational to enterprise applications rather than a checklist item.
Securing Stripe API Keys in AWS with automatic rotation
The article presents a production-grade approach to securing Stripe API keys in AWS, motivated by the risks and operational limits of basic secret storage for payment processing. It compares AWS Parameter Store with Secrets Manager, emphasizing built-in rotation, CloudTrail audit trails, IAM integration, larger secrets, and cross-account access despite higher cost. The implementation uses environment-specific secret paths, tags, and IAM conditions to isolate development, staging, and production credentials, with separate rotation schedules. For zero-downtime rotation, applications refresh cached credentials after authentication failures while both old and new keys remain valid during a transition. The design also covers CloudWatch monitoring, emergency rotation procedures, cross-region replication, region-specific schedules, and cost considerations, concluding that ongoing review is necessary for secure and reliable payment operations.
Building rock-solid Stripe integrations: A developer's guide to success
The guide presents ten practices for building production-ready Stripe integrations, covering payment forms, subscriptions, and operational concerns. It recommends verifying webhook signatures with the Stripe-Signature header and endpoint secret, recording event IDs for idempotency, and returning a fast 2xx response while processing asynchronously. Test and live API keys, webhook endpoints, logs, and monitoring should remain separate, while error handling should distinguish card, request, and API failures and use exponential backoff for retries. The guide also recommends testing successful, declined, insufficient-funds, and 3DS scenarios with Stripe test cards, alongside simulated webhook events. Its conclusion emphasizes edge-case planning, logging, monitoring, and ongoing review as foundations for reliable, secure payment processing that can scale with business needs.
New to Stripe? Learn the key concepts for software developers.
The guide introduces software developers to Stripe’s main objects and workflows for integrating payments, recurring billing, and related account activity. It begins with Payment Intents, which specify an amount and currency, track a payment’s lifecycle, and produce a client secret for completing the frontend flow, then covers Payment Methods and Customers, including Setup Intents and attaching a default payment method. For subscriptions, it distinguishes Products, Prices, and Subscriptions, and explains using events and webhooks to react to asynchronous payment and subscription changes while verifying webhook signatures. It also describes Disputes, refunds, and expanded API responses, including retrieving related resources in one call. The guide recommends starting in test mode and using dashboard logs while consulting Stripe’s documentation and changelog as the platform evolves.
How to Submit Your System for Cross
Enterprise applications with SSO still need scalable identity management for customer organizations, including user provisioning, updates, and deprovisioning. This guide presents SCIM (System for Cross-domain Identity Management) as the standards-based connection to Okta for automating those lifecycle operations and controlling access. SCIM can synchronize users in real time as employees join, leave, or change roles, while reducing manual work and inconsistent deprovisioning risks. To submit the integration to the Okta Integration Network, partners need an Okta Integrator Free Plan, two Runscope test links for CRUD and SPEC tests, manual Okta SCIM integration tests, a provisioning-enabled instance, confirmation, and a publicly accessible SCIM server. The submission can expose an integration to Okta’s customer base of 18,000+ organizations and provide verified enterprise-ready status.
Embracing passwordless authentication with Grab’s Passkey
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.
Japan community highlights: Effective testing and security
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.
Related topics
All topics →Weekly digest
The best engineering reads, once a week.