Loading…
Okta
Identity and access management company providing authentication, authorization, single sign-on, and identity security solutions.
- 69 posts summarised
- latest
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.
From their blog
Latest articles
Introducing xaa.dev: A Playground for Cross App Access
xaa.dev is a free, beta playground for exploring Cross App Access (XAA) end to end without local setup, infrastructure provisioning, or signup. It addresses the difficulty of testing XAA, which otherwise requires configuring an Identity Provider, resource authorization server, resource API, and requesting application before a token exchange can be observed. The site pre-configures these roles and guides users through authentication, token exchange, access token request, and resource access while exposing requests, responses, and cryptographic claims. Developers can also connect their own apps, including MCP clients, and test both OIDC and SAML identity assertions; it is currently in beta and requires no account.
Okta Developer Connect Recap
Okta Developer Connect Bengaluru was Okta’s first flagship Developer Connect event in India, bringing developers, architects, engineering managers, IAM practitioners, and technology leaders together to discuss identity as systems scale and AI agents work alongside humans. Sessions framed identity as foundational infrastructure spanning users, applications, APIs, services, and AI agents, while connecting core standards and practices to platform use cases including the Okta MCP Server, Cross App Access, Okta Integration Network, Okta Workflows, lifecycle management, and Verifiable Digital Credentials. Interactive discussions, audience Q&A, quizzes, surveys, and a research panel complemented talks and enabled exchanges with Okta engineers, product leaders, and advocates. The Bengaluru event begins an ongoing series intended to support practical identity education and open technical dialogue about enterprise-ready systems, identity standards, and AI-driven access and security assumptions.
Unlock the Secrets of a Custom Sign-In Page with Tailwind and JavaScript
This tutorial shows how to customize an Okta-hosted sign-in page for a fictional to-do application while retaining the Okta Identity Engine and Sign-In Widget (SIW). It starts with a custom domain and brand configuration, then uses the page code editor, SIW design tokens, custom text, Tailwind CSS via CDN, and external JavaScript behavior to create a responsive layout, branded footer, and terms-and-conditions modal. The modal uses Alpine.js transitions and a MutationObserver watching the authentication container so it appears after SIW elements render; Google Fonts also require CSP allowlist entries for googleapis.com and gstatic.com. The post notes that browser manipulation can bypass the modal, recommends accessibility testing after customization, and describes connecting the brand to an Okta React sample through an OIDC custom issuer URL.
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.
Stretch Your Imagination and Build a Delightful Sign-In Experience
This tutorial shows how to customize the Okta-hosted Sign-In Widget (SIW) for a fictional to-do application while retaining Okta Identity Engine authentication flows. It covers configuring a custom domain and enabling SIW Gen3, then using brand settings, design tokens, custom CSS properties, and page code to change fonts, colors, layout, and background treatment. The implementation uses the widget’s afterTransform method and FormBag to revise the identify form, remove help, unlock, and divider elements, change the title, and add a custom blog link. It also explains the default HTML and JavaScript rendering configuration and describes updating an OpenID Connect application to use the brand’s custom sign-in URL as its issuer.
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.
Build Secure Agent-to-App Connections with Cross App Access (XAA) Using OIDC
The guide presents Cross App Access (XAA) as a protocol for secure agent-to-app and app-to-app access, giving enterprise IT centralized control over connections, policies, and accessed resources. It walks through an OIDC demonstration using Todo0 as the Resource App, Agent0 as the Requesting App, and Okta as the enterprise identity provider, covering app registration, trust establishment, token exchange, and API calls. The flow uses the OAuth 2.0 Identity Assertion Authorization Grant: Bob logs in once, Agent0 obtains an identity assertion, Okta exchanges it for a Todo0 access token, and Agent0 calls the protected API. The demonstrated result is an agent that can read pending tasks, add tasks, and mark tasks complete, with changes reflected in Todo0. The guide is marked out of date because its Admin Console instructions have been replaced by AI agent registration under Directory > AI Agents.
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.
Find the intersection of security, AI, IAM, and fun at Oktane
Oktane 2025 will focus on security, AI, and identity, with programming for protecting software systems that use both human and non-human identities. The event is scheduled for September 24–26, 2025, at Caesars Forum in Las Vegas, and will include the Oktane Developer Lounge, Expo Hall activities, lightning talks, documentation feedback games, and Developer Support consultations. Hands-on labs cover securing enterprise AI with the OAuth Cross App Access (XAA) extension and Model Context Protocol (MCP), automating Okta with Terraform, replacing standing administrative access with time-bound requests through Okta Identity Governance and Workflows, and using OAuth 2.0 Demonstrating Proof of Possession (DPoP) tokens in a single-page application. An Okta Workflows community meetup will add networking, drinks, and appetizers, while the broader event offers learning, expert conversations, and application-focused discussions.
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.
Integrate Your Enterprise AI Tools with Cross App Access (XAA)
Enterprise AI tools increasingly use protocols such as Model Context Protocol (MCP) to request data and resources from work applications, creating identity and authorization challenges that ordinary app-to-app consent does not expose to enterprise administrators. Cross App Access (XAA) places the enterprise identity provider between the requesting application and resource application by combining OAuth Token Exchange (RFC 8693), JWT Profile for Authorization Grants (RFC 7523), and the Identity Assertion Authorization Grant profile. In the illustrated flow, a user signs in to Agent0, the IdP issues an ID token, and Agent0 exchanges it for an ID-JAG targeted at Todo0’s authorization server. Todo0 validates that assertion and returns its normal access token, enabling MCP requests without interactive consent while allowing enterprise policy checks. The design leaves access-token format and validation with the resource application, while refresh-token behavior remains to be defined to balance policy enforcement and session continuity.
Superheroes, Startups, and Security: Sohail's Path to Developer Advocacy at Okta
Sohail Pathan describes his path from Android development to a Senior Developer Advocate role at Okta, tracing how curiosity about technology grew into community and developer relations work. After studying Computer Science and adopting Kotlin for Android app projects, he moved from an EdTech startup’s Android team into its first Developer Community Manager role, organizing meetups, answering forum questions, and supporting learners. At a deeptech startup, he led Developer Relations for a cloud-based Android Studio tool, using meetups, hackathons, and feedback to seek product-market fit before technical roadblocks and limited demand forced closure after four months. At ApyHub, he created Go and Node.js tutorials, sample apps, API documentation, and community programs while gaining hands-on experience with REST architecture, microservices, API gateways, containers, load balancing, DevOps, OAuth, and identity management. He says that exposure led him to Okta, where he plans to share API and identity knowledge with its community.
Changes Are Coming to the Okta Developer Edition Organizations
Okta is replacing Developer Edition organizations with the Integrator Free Plan as the default developer organization type on May 22, 2025, as part of architectural changes tied to its Secure Identity Commitment. The new organization is intended for iterative integration development, identity-flow validation, and OIN preparation, not production use, and provides access to expanded testing offerings and support resources. Existing Developer Edition organizations begin deactivation on July 18, 2025, in batches, after which users lose access to their organizations and resources. Migration choices include recreating resources with automation, generating Terraform configurations with Terraformer, or using EnvSync to back up supported objects and recreate many of them. Published OIN integrations remain available, but linking them to the new account requires contacting Okta; draft or in-review submissions from Developer Edition must be approved by June 9 or will be automatically declined and require resubmission.
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.
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.
How to Build Secure Okta Node.js Integrations with DPoP
Okta management API integrations can use a Node.js service app with OAuth 2.0 client credentials, but a bearer access token can be replayed by anyone who obtains it during its one-hour lifetime. The tutorial configures Okta for private_key_jwt authentication, grants the okta.users.read scope and Read-only Administrator role, and builds a Node.js service that requests and caches an access token. It then enables Demonstrating Proof of Possession (DPoP), handles an initial use_dpop_nonce response by retrying the token request with a nonce-bound proof, and generates a fresh proof for each API call. Each request binds the proof to the access token through the SHA-256-based ath value and uses DPoP rather than Bearer authorization. The demonstrated service successfully lists users through Okta Admin Management API endpoints.
How to Create a Secure CI/CD Pipeline Using Okta Terraform
The guide presents a secure CI/CD pipeline for managing Okta resources with Terraform, AWS, and GitHub Actions, addressing local setup, collaboration, state storage, secrets, and deployment automation. Its architecture uses GitHub as source control and workflow trigger, GitHub OIDC to authenticate to AWS IAM STS and assume roles, S3 for Terraform state, DynamoDB for state locking, and AWS Secrets Manager for Okta OAuth 2.0 client credentials private keys. Developers push changes to develop for an automatic development build, open a pull request to main for a production plan, and merge approved changes to trigger the production build. The workflows run Terraform init, plan, and apply as appropriate, while the guide also covers repository setup, branch organization, and troubleshooting for missed configuration in GitHub, Okta, or AWS.
Topics they write about
All topics →Weekly digest
The best engineering reads, once a week.