Okta Developer

Introducing Okta Journeys: A Better Way for Developers to Learn Identity

Tue, 07 Jul 2026 00:00:00 -0500

Learning identity management is hard enough. Navigating Okta’s documentation to build something shouldn’t be. If you’ve ever lost an afternoon stitching together how-to guides, product docs, and scattered blog posts just to figure out where to start, you’re not alone – and we’ve heard you, loudly and repeatedly.

Today, we’re excited to announce the official launch of Journeys: a new way to navigate Okta documentation built around the tasks you’re actually trying to accomplish.

What are Okta Journeys for developers?

A Journey is a curated, expert-driven, end-to-end guide built around a small-to-medium-sized development project. Rather than sending you to find a single document and piece the rest together yourself, each Journey walks you through the entire project, from foundational concepts to completion.

Journeys address the most frequent questions we’ve heard from developers. Every Journey includes both brand-new material and revised content to ensure that what you’re reading is accurate, up to date, and genuinely useful.

Each Journey organizes content into three main sections.

Learn identity foundations

Before you write a single line of code, it helps to know the terrain. The Learn section anchors the broad “identity” concept, covering foundational knowledge including Okta features, software development kits (SDKs), and application programming interfaces (APIs) relevant to your task. Whether you’re new to Okta or just unfamiliar with a specific area, this section gives you the vocabulary and mental model you need to make informed decisions. It ensures you’re not just following steps, but truly understanding the technology and concepts underlying your project.

Plan your customer identity implementation

Good implementations start with good planning. The Plan section walks you through the key decision points to consider before you begin – from the pros and cons of migration strategies and deployment models to configuration options, rate limits, and key performance indicators (KPIs). These are all common concerns from the field. Decisions made here shape everything that follows, so you won’t discover them for the first time mid-build.

Build and implement identity solutions

This is where everything comes together. The Build section presents a carefully curated collection of resources, organized to guide you through your project from start to finish. No more hunting across technical content channels to find the correct how-to guide, configuration advice, Knowledge Base (KB) article, blog post, API endpoint details, or videos. Everything you need is in one place, in the right order.

Every Journey covers the Okta-recommended approach and adds common alternatives when practical, because we know one size doesn’t always fit all.

Six Okta Journeys available now

The first six Journeys are live today, targeting Okta Customer Identity (OCI) builders developing and securing customer-facing portals. If you’re working on user authentication, registration, company branding, or user management, these Journeys are for you.

Explore Journeys

What’s next: Okta for AI agents and more

This is just the beginning. We’re already building new Journeys to tackle high-impact, emerging scenarios, including:

Okta for AI Agents: Detect, identify, manage, register, and govern your AI agents.
Building for the Okta Integration Network (OIN): Journeys for developers building different types of integrations for the Okta Integration Network.
Classic Engine to Okta Identity Engine Migration: Update your org to Okta Identity Engine and remove the Classic Engine-specific code from your apps.

We are committed to continuously expanding this library so that, no matter your development goal, you have a clear, expert-guided path to success.

Tell us what you think

These Journeys will fundamentally improve your development experience. Explore them, share your feedback, and let us know what Journeys you’d like to see next. Use the feedback tab on the Journey page, reach out to us on the Okta Developer Forums, or find us on socials.

Happy building.

Remember to follow us on X and subscribe to our YouTube channel and LinkedInfor more exciting content. We also want to hear from you about the topics you’d like to see and any questions you may have. Leave us a comment below!

How to Build and List Secure Cross App Access (XAA) Connections on Okta Integration Network (OIN)

Mon, 06 Jul 2026 00:00:00 -0500

AI agents have evolved from novelties into active participants in enterprise workflows. They now operate across systems, reading data, executing actions, and calling APIs on behalf of users.

This evolution creates a new security hurdle for enterprises. Software and agents need to connect without relying on static API keys, scattered OAuth consent, or unmanaged integrations. Cross App Access (XAA) addresses this by bringing these connections under the enterprise identity layer.

Table of Contents

What is Cross App Access (XAA)?
Why Cross App Access (XAA) matters for ISVs and their customers
Prerequisites for supporting Cross App Access (XAA) in your app
Implementation and testing guide for Cross App Access (XAA) with Okta as IdP
Getting listed in the Okta Integration Network (OIN)
- XAA enablement questionnaire
- What happens next after you submit your OIN and XAA request?
Need help with your Cross App Access (XAA) submission?
Learn more about Cross App Access and the Okta Integration Network

What is Cross App Access (XAA)?

Cross App Access (XAA) is an identity framework that secures token-based communication when software or AI agents request data from external ecosystems, and those apps have an established trust relationship with an Identity Provider (IdP). It replaces insecure, long-lived API keys or hardcoded secrets with a pattern for real-time identity propagation between different application vendors.

Watch the video below to see Cross App Access (XAA) in action:

A concrete way to think about it: consider an employee using an AI assistant to prepare for a meeting. The assistant might need to pull tasks from one application, notes from another, and account details from a third. Without XAA, every connection might require separate user permissions, distinct API keys, or custom administrative work.

XAA allows enterprises to centrally determine which apps connect, which scopes they request, and which users gain access. This streamlines the user experience while giving the enterprise the control it requires.

Why Cross App Access (XAA) matters for ISVs and their customers

Every time an AI agent or application accesses another system without a proper identity handshake, customers face security and compliance risks. XAA eliminates this gap, providing IT teams with the visibility and audit trails they need to govern cross-app identity flows.

For ISVs, XAA adoption simplifies the integration process in enterprise environments where security and visibility remain top priorities. It demonstrates trust to buyers, showing that your application fits into a secure, modern ecosystem. As enterprises increase their expectations for secure integrations, XAA readiness becomes a powerful competitive differentiator.

At a high level, XAA involves three distinct roles:

Requesting app: the requesting app acts on behalf of the user but does not mint the identity assertion itself. Instead, it receives an ID token or Security Assertion Markup Language (SAML) assertion from the identity provider and exchanges that assertion for an Identity Assertion Authorization Grant (ID-JAG), a JSON Web Token (JWT).
Resource app: the resource app owns the API or data. It validates the incoming ID-JAG and issues a scoped access token if the request is valid.
Identity Provider: authenticates the subject, evaluates access policies, and generates the necessary ID-JAG. Okta fills this role in an XAA deployment.

Prerequisites for supporting Cross App Access (XAA) in your app

Before you start building, ensure you have these prerequisites in place:

Defined app role: determine if your app will function as a requesting app, a resource app, or both.
Authorization server support: if your app acts as a resource app, your authorization server must validate the ID-JAG and issue a scoped access token for the protected resource.
Scopes and protected resources: if you are building a resource app, clearly define the APIs and scopes available to requesting apps.
Okta Integrator Free Plan org: use this org to build, test, and submit your integration. You can register for a new account. After signing up, email developers@okta.com to enable the XAA feature for your org.
Single Sign-On (SSO) integration: XAA relies on the trust your existing SSO already establishes. Ensure your app supports OpenID Connect (OIDC) or SAML SSO with Okta.
Tested workflows: you must demonstrate that XAA works with Okta as the IdP before requesting XAA enablement for your Okta Integration Network (OIN) integration.

Implementation and testing guide for Cross App Access (XAA) with Okta as IdP

To begin development, select the guide corresponding to your application’s authentication protocol:

If your app uses SAML for SSO, follow our SAML implementation guide.
If your app uses OIDC for SSO, refer to the OIDC implementation guide.

To verify your configuration, demonstrate a successful token exchange:

Requesting apps: provide evidence that you successfully obtained an ID token via OIDC SSO and used it to mint an ID-JAG.
Resource apps: show that your app received an ID-JAG and successfully exchanged it for a scoped access token.

Completing these tests is a hard requirement for approval; please ensure they are successful before submitting your integration.

Getting listed in the Okta Integration Network (OIN)

Listing your integration on the Okta Integration Network (OIN) helps customers discover and trust it. Because XAA relies on trust that your existing single sign-on (SSO) configuration already establishes, you must list an OIDC or SAML SSO integration on the OIN before proceeding.

If your app is not yet listed, prioritize that submission. Submit your SSO app through the OIN Wizard. This Okta Integration Network guide walks you through everything you need to get your integration listed, from app metadata to SSO configuration. Once you submit your SSO app for review, you can begin the XAA enablement request in parallel.

XAA submissions currently require a manual step: you need to contact Okta directly to indicate that your submission includes XAA support. When your app successfully passes token exchange tests, email the Okta team at oin@okta.com to request XAA enablement. To speed up the review and avoid additional rounds of configuration, include the completed questionnaire below in your email.

Use this subject line: Request to enable XAA support for <App Name> on OIN

XAA enablement questionnaire

General app details:

App Name:
Okta Integrator Org domain:
SSO Mode: OIDC / SAML
XAA App Role: Requesting app / Resource app / Both
Existing OIN App Link, if already published
Submission Type: new OIN submission / update to an existing OIN app

Requesting app details: fill this out if your app acts as a requesting app.

Resource Registration Pairs: for each resource app you connect with, provide:
- Resource app name
- Authorization Server Issuer URL
- Registered Client ID
Supported Scopes: list the scopes your app requests from resource apps.
Client ID Metadata Documents (CIMD) Support:
- If yes, please provide the CIMD URL
- No
- Planned future support

Resource app details: fill this out if your app acts as a resource app.

Global Issuer URL: the endpoint that processes ID-JAG token exchange requests
Protected Resource Identifiers: URLs of the APIs your app exposes (e.g., https://api.yourdomain.com/v1)
Supported OAuth Scopes: scopes allowed for XAA token exchange (e.g., openid, read, write)
CIMD Support:
- If yes, please provide the CIMD URL
- No
- Planned future support
Well-Known Host Endpoints: specify whether you host either of the following:
- .well-known/oauth-authorization-server
- .well-known/oauth-protected-resources

Testing details:

If you’re a requesting app: confirm that you generated successful token exchange logs. The Okta operations team can verify these via internal telemetry parameters. To help the team validate quickly, also include:
- Test org
- App name
- Test user or test account used
- Resource app tested against
- Scopes requested
If you’re a resource app: attach a screenshot or a short video showing successful ID-JAG validation and scoped access token exchange logs directly from your authorization server. These cannot be verified externally, so the evidence needs to come from you. Please include:
- Resource endpoint tested
- Scopes granted
- Token exchange result

What happens next after you submit your OIN and XAA request?

Once you submit your request, the Okta team reviews your SSO submission, XAA metadata, and testing evidence. If your app is already on the OIN, we will update the existing listing after approval. For new integrations, we complete the standard SSO review before publishing your app with XAA support. If the team needs further clarification or additional testing evidence, we will contact you directly.

Need help with your Cross App Access (XAA) submission?

Please reach out to developers@okta.com for help. You can also find answers and connect with peers in our developer community.

XAA advances how apps and agents interact securely. By supporting this standard and listing your integration on the OIN, you help enterprise customers adopt AI-driven automation with better governance, stronger identity control, and increased confidence.

Learn more about Cross App Access and the Okta Integration Network

If this guide helped you plan your OIN and XAA submission, explore these resources next:

📘 Cross App Access documentation: official guides for configuring and managing Cross App Access in production.
📄 Okta Integration Network documentation: everything you need to get your SSO integration listed on the OIN.
🔐 Enabling Cross App Access for SAML-based enterprise apps: the implementation guide for SAML SSO apps.
🔑 Build secure agent-to-app connections with Cross App Access (XAA): the implementation guide for OIDC SSO apps.
🎙️ Developer podcast on MCP and Cross App Access: hear the backstory, use cases, and why this matters for developers.

Enabling Cross App Access for SAML-Based Enterprise Apps

Fri, 03 Jul 2026 00:00:00 -0500

If you currently federate enterprise customers using Security Assertion Markup Language (SAML) and want to allow AI agents to access your API without migrating to OpenID Connect (OIDC), this Cross App Access (XAA) guide is for you.

The Identity Assertion Authorization Grant specification, the basis of XAA, was originally designed with OIDC in mind. To use it in SAML applications, you must accommodate specific security and uniqueness requirements. This guide details what you need to support and how to verify SAML-derived claims at your resource authorization server.

Table of Contents

How XAA in SAML works
Analyzing the ID-JAG claims
XAA implementation checklist for SAML-federated applications
Making cross-application requests from your SAML app securely
Configure your XAA SAML App in Okta
- Create the SAML 2.0 app in Okta
- Register and configure the AI Agent in Okta
Verify your Okta XAA setup on xaa.dev
Takeaways for implementors who have both OIDC and SAML apps
Learn more about Cross App Access, SAML, and OAuth 2.0

How XAA in SAML works

When an agent (like one running in Claude) needs API access, it presents an Identity Assertion Authorization Grant (ID-JAG). The ID-JAG is a short-lived JSON Web Token (JWT) issued by the customer’s Identity Provider (IdP) for your authorization server. Your resource server accepts the token, identifies the user, and issues your own access token, all while leaving the customer’s existing SAML integration untouched.

The sequence diagram shown below describes the SAML XAA flow. Notice that the SAML SSO flow stays the same; the only change is the section highlighted with the comment “Your Resource Authorization Server (AS): redeem and resolve”. You’ll make a POST request to your resource’s authorization server with the ID-JAG, resolve the NameID to return an access token that you’ll use for resource requests.

⚠️ Note

You are not processing SAML here. The only artifact crossing from the IdP to your domain is the ID-JAG. All SAML-related tasks, such as SSO, assertion handling, and subject derivation, happen upstream. Your responsibility is to validate the ID-JAG, redeem it for an access token, and resolve the user from the claims.

Analyzing the ID-JAG claims

When you decode the ID-JAG, you’ll see claims in the header and payload that impact how you process the access request:

// header
{
  "typ": "oauth-id-jag+jwt",
  ...
}

// payload
{
  "iss": "https://atko.okta.com",
  "sub": "00u1a2b3c4D5e6F7g8h9",
  "sub_id": {
    "format": "saml-nameid",
    "issuer": "http://www.okta.com/exk1fcia8zMValiD0h8",
    "nameid": "alice@atko.com",
    "nameid_format": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress",
    "sp_name_qualifier": "https://chat.example/saml/metadata"
  },
  "aud": "https://auth.chat.example",
  "client_id": "0oa8claudeMcpAtYourAS",
  "email": "alice@atko.com",
  "scope": "chat:read chat:write",
  "jti": "id-jag-7f3c9a21b8",
  ...
}

Focus on these key claims noted in the decoded ID-JAG payload:

sub_id: This is the primary field for user resolution
aud: Indicates the endpoint URL for the resource authorization server
client_id: This is the client’s ID at your resource authorization server, which might differ from its ID at the IdP
email: Recommended by the specification for just-in-time provisioning if the user has not yet signed in
jti: This is the unique ID for the ID-JAG JWT that prevents replay attacks within the validity window

XAA implementation checklist for SAML-federated applications

To fully support Cross App Access, implement these five steps in sequence:

How XAA in SAML works
Analyzing the ID-JAG claims
XAA implementation checklist for SAML-federated applications
Making cross-application requests from your SAML app securely
Configure your XAA SAML App in Okta
- Create the SAML 2.0 app in Okta
- Register and configure the AI Agent in Okta
Verify your Okta XAA setup on xaa.dev
Takeaways for implementors who have both OIDC and SAML apps
Learn more about Cross App Access, SAML, and OAuth 2.0

Mapping user identity in the SAML `NameID` attribute

Unlike OIDC apps, which typically resolve users from the sub claim, SAML-federated apps do not have a corresponding sub claim in their SAML assertion. Consequently, they often lack a direct way to map users without using the sub_id field.

You must compare every member of the saml-nameid identifier used as a subject key for a given SAML issuer. Do not resolve based on the NameID alone unless your local policy permits it.

The NameID field alone doesn’t uniquely identify a user, since two organizations could each have an employee named Alex Chen. This problem is analogous to resolving user uniqueness in multi-tenant applications.

Resolve on NameID + sp_name_qualifier together; the combination of both fields provides the unique user identity required.

⚠️ Note

Don’t assume the NameID is an email address; it is whatever the customer’s SSO emits. Your matching set must remain consistent across your deployment.

Validating the ID-JAG and resolving the user

The client posts the ID-JAG as a JWT authorization grant and authenticates with its credentials at your server. Below is an example HTTP request for requesting an access_token

POST /oauth2/v1/token HTTP/1.1
Host: chat.example
Authorization: Basic <base64(client_id:client_secret)>
Content-Type: application/x-www-form-urlencoded
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
&assertion=eyJ0eXAiOiJvYXV0aC1pZC1qYWcrand0...

Before processing, you must bind the ID-JAG’s iss to a registered SAML connection to prevent forgery.

If you verify the signature before checking the issuer binding, an attacker could potentially create their own IdP, sign a token, and use your customer’s SAML issuer as the sub_id.

Always resolve the connection from the iss first, then verify the signature against that connection’s key. You’ll compare this using the JSON Web Key Set (JWKS) metadata.

Below is the pseudocode for implementing the validation and resolving a user:

connections = {
  "https://atko.okta.com": {
    jwks:            "https://atko.okta.com/oauth2/v1/keys",
    samlIssuer:      "http://www.okta.com/exk1fcia8zMValiD0h8",
    spNameQualifier: "https://chat.example/saml/metadata",
  },
}

redeem(idJag, authenticatedClient):
    // 1. Bind iss to a connection before trusting the signature.
    iss  = unverified_issuer(idJag)
    conn = connections[iss]
    if conn is none: reject "invalid_grant"

    // 2. Verify signature against the specific issuers JWKS.
    payload = verify_jwt(idJag, jwks = conn.jwks)
    if payload is invalid: reject "invalid_grant"

    // 3-5. Perform remaining checks.
    require payload.typ       == "oauth-id-jag+jwt"
    require payload.aud       == "resource_authorization_server_url"
    require payload.client_id == authenticatedClient.id

    user  = resolveSamlSubject(payload.sub_id, conn)
    scope = applyScopePolicy(user, payload.scope)
    return issueAccessToken(user, scope)

resolveSamlSubject(subId, conn):
    require subId and subId.format == "saml-nameid"
    require subId.issuer == conn.samlIssuer
    require subId.sp_name_qualifier == conn.spNameQualifier

    user = lookup_user_by_saml_nameid(subId.issuer, subId.nameid, subId.sp_name_qualifier)
    if user is none: reject "invalid_grant"
    return user

Issuing the access token

Once you resolve the user, issue an access_token scoped according to your local policy. Below is an example of an access_token returned after successfully validating the ID-JAG and resolving the user.

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store

{
  "token_type": "Bearer",
  "access_token": "2YotnFZFEjr1zCsicMWpAA",
  "expires_in": 86400,
  "scope": "chat:read chat:write"
}

⚠️ Note

Do not issue a refresh token. If your authorization server issues a refresh token, the client has durable access to your resource server, and the IdP cannot revoke access.

The ID-JAG replaces the need for a refresh token. On access token expiry, the client resubmits the same ID-JAG to your token endpoint, and you mint a new access token against it. Only once the ID-JAG itself expires does the client request a new ID-JAG from the IdP using its own refresh token.

Updating authorization server metadata

Clients locate your XAA support via your authorization server metadata (/.well-known/oauth-authorization-server). Ensure you include the supported fields:

{
  "issuer": "https://chat.example",
  "token_endpoint": "https://auth.chat.example/oauth2/v1/token",
  "grant_types_supported": [
    "urn:ietf:params:oauth:grant-type:jwt-bearer"
  ],
  "authorization_grant_profiles_supported": [
    "urn:ietf:params:oauth:grant-profile:id-jag"
  ]
}

Making cross-application requests from your SAML app securely

With these five steps complete, your SAML application is configured for Cross App Access. Agents can now authorize requests against your API while maintaining your existing production federation, eliminating the need for protocol migration.

You can now use Okta to make cross-application requests with your SAML app.

Configure your XAA SAML App in Okta

Let’s test your SAML application in Okta. Before you begin, you’ll need some configuration values from the xaa.dev site.

Navigate to https://xaa.dev/developer/test-resource?tab=saml-okta. You’ll need two values, the Single Sign-On URL – this is the Assertion Consumer Service (ACS) URL – and the Audience URI (SP Entity ID).

Keep this site open in your browser; you’ll return to it throughout the setup.

Create the SAML 2.0 app in Okta

Before you begin this step, you’ll need an Okta Integrator Free Plan account. Sign up for a new account to test out the XAA features.

Cross App Access is an early access feature in Okta. New Integrator Free Plan account types include XAA support. If you have a paid Okta org plan and the following options are missing, contact your representative.

Enable AI Agent Identity Assertion:

Navigate to Settings > Features > Early Access
Find AI Agent Identity Assertion and Agent to Agent Connections, and enable both

You’ll need an Okta application representing your requesting and resource apps.

If you don’t have Okta SAML 2.0 applications representing your requesting and resource apps, you’ll need to create them. Create Okta SAML 2.0 applications by following these instructions.

Navigate to Applications > Applications.

Select Create App Integration. In the Create a new app integration modal, select SAML 2.0 and press Next.

In General Settings:

App name: Enter a descriptive name for the app, for example, “Test Requesting App” or “Resource App”
Press Next to continue

In Configure SAML:

Single sign-on URL: Use the ACS URL of your requestor or resource app, e.g., “https://idp.xaa.dev/saml-requester/acs”
Audience URI (SP Entity ID): Use the SP Entity of your requestor or resource app, e.g., “https://idp.xaa.dev/saml-requester/metadata”
Name ID format: select EmailAddress
Application username: select Email
Update application username on: select Create and update
Press Next to continue

Press Finish to create the Okta SAML 2.0 application.

After creating the app, you’ll see more configuration options for your Okta SAML 2.0 app. You’ll make changes in more than one tab.

Sign On configuration

Select the Sign On tab. Locate the Metadata URL field and press Copy to save it to your clipboard. You’ll paste this URL to the SAML app metadata URL field in xaa.dev and save.

Your SSO endpoint and Token endpoint are automatically configured.

Assignments configuration

Navigate to the Assignments tab and make the following configuration changes:

Select Assign > Assign to People
Search for your test user and select Assign
Press Save and Go Back, then select Done

Note

If you don’t have a SAML 2.0 application representing the resource app, you will need to create one with the same steps above. However, there’s an extra configuration step for resource apps to enable XAA. Ensure your resource apps have XAA enabled. Don’t set the configuration for requesting apps.

Resource Server extra configuration

Navigate to the Resource Server tab and make the following configuration changes:

Select Enable XAA
Issuer URL: Use your resource authorization server issuer URL. This value becomes the aud claim in the ID-JAG and cannot change without deleting and resetting the connection.

Register and configure the AI Agent in Okta

With your Okta SAML 2.0 requesting app configured, register a new AI Agent in Okta. The AI Agent configuration represents the relationship between the Okta SAML 2.0 app you created and your MCP Resource Application. You’ll configure credentials, add your requesting app as a delegated caller, and connect your MCP resource app as a Resource Connection.

In the Okta Admin Console:

Navigate to Directory > AI Agents
Select Register AI Agent > Register Manually
Enter a Name, e.g., “Requesting Agent”
Select Register

Select the AI Agent you just created to open its configuration. Configure the agent across the following tabs:

On the Owners tab
1. Select Assign individual owners
2. Search for and add yourself as an owner
3. Press Save
On the Credentials tab (select on the Requesting Agent to see this tab)
1. Copy the AI agent ID
2. Open the xaa.dev site to add theAI agent ID value as the Client ID and save
3. Back in Okta, select the Add Public Key, and then press Generate new key. Okta generates a key pair and displays the private key. Under PEM, press Copy to clipboard and store the key safely. You’ll paste this private key into the Private key (PKCS8 PEM or private JWK) field in xaa.dev and save.
On the Delegations tab
1. Select Add Caller
2. Search for the newly created Okta SAML requesting app
3. Select Add Caller to confirm
On the Resource Connections tab
1. Select Add Resource Connection. Under the Resource section, select Application as the resource type.
  1. Under the Application section, choose your Application instance – MCP (Resource App) – from the dropdown menu and paste the Client ID at the Resource Authorization Server.
2. Under Scope Condition, select Allow all
Activate the agent
1. Select the three dots (the kebab menu), to display options
In the drop-down menu, select Activate

Confirm the AI Agent configuration is complete. All checkmarks on the agent configuration page must be green.

Verify your Okta XAA setup on xaa.dev

Before we get to the next section, make sure you have the resource app URL in the resource authorization issuer (ID-JAG audience). By this point, you’ll have every value from the checklist and your one-time Okta setup in place (AI Agent, credentials, owner, delegation, and resource connection), so we’ll add the values from Okta and the apps to walk through the flow step by step, one button per step.

The screenshot below shows the SAML configuration values step on xaa.dev.

Configure SAML SSO

Press Start SAML login at your IdP and complete the login in the pop-up.

When it closes, the step turns green and shows a ✓ Auto-discovered SSO endpoint, confirming that the tester resolved the real .../sso/saml endpoint from your metadata and returned a signed SAML assertion.

Confirm the SAML Assertion exchange for a refresh token

Press Exchange assertion for refresh token. The tester posts the signed assertion to your IdP’s token endpoint, using private_key_jwt authentication. A 200 means the identity provider accepted the assertion, and you now hold an opaque refresh token.

Verify the refresh token exchange for an ID-JAG token

Press Exchange refresh token for ID-JAG. This action returns a decoded ID-JAG. Take a second to review it: aud should equal your Resource authorization issuer, and sub_id should contain the SAML NameID of the user who logged in. The Resource authorization server then validates this token. A 200 OK indicates that the step succeeded.

Redeem the ID-JAG for an access token at the resource authorization server

Fill in your Resource AS token endpoint
Client ID and client secret of the resource app from the Resource Authorization Server

Press Redeem (grant_type=jwt-bearer). If the request succeeds, you’ll receive a 200 OK response with an access token. Inspect the token in the Token tab to verify that theiss, aud, and scope claims match the values configured in your resource authorization server. This validation confirms that the authorization server accepted the ID-JAG and issued its own access token.

Call the resource API with the access token

Select the request method and enter your API URL (The Authorization: Bearer header is added automatically, but you can add any other headers or a request body as needed), then press Send GET Request. A 200 response from your endpoint is the final proof: your API accepts the access token generated by the ID-JAG exchange.

Prove the XAA connection end-to-end

A green Conformance passed panel appears. Select Export conformance log (JSON) to download the test results. The export includes the signed ID-JAG, the access token returned by your resource authorization server, and the API response.

You can share this file with your IdP as proof that the Cross App Access integration works successfully.

Takeaways for implementors who have both OIDC and SAML apps

If you have already implemented XAA in your OIDC apps, here’s a quick checklist to convert your SAML apps:

The subject comes from sub_id in saml-nameid format, rather than sub
Match on every saml-nameid member (issuer + NameID + sp_name_qualifier), rather than just iss and sub
Everything else, including token issuance rules and redemption checks, remains as is

Learn more about Cross App Access, SAML, and OAuth 2.0

If this guide helped you implement Cross App Access with SAML, explore these resources:

📘 Cross App Access Documentation: Official guides for configuring and managing Cross App Access in production.
🎙️ Developer Podcast on MCP and Cross App Access: Hear the backstory, use cases, and why this matters for developers.

Identity 101:

The Builder Revolution: Why We're Shifting to Builder Advocacy

Tue, 30 Jun 2026 00:00:00 -0500

My team has officially changed its name, and it’s one I’ve been excited about for a while.

My team is now Builder Advocacy, and our organization is now Builder Experience (BX). We were previously known as Developer Advocacy and Developer Success, respectively.

On the surface, it might look like a simple rebranding. But it’s not. It’s a recognition of something that’s been happening in our industry for a while and has accelerated dramatically recently with this understanding: the definition of who builds things with technology has fundamentally changed.

The builder revolution is already here

For most of computing history, “developer” meant someone who wrote code; they were someone who knew a language, understood a framework, and could navigate a terminal.

That world has changed.

According to the GitHub Octoverse 2025 report, GitHub now has over 180 million developers, with more than one new developer joining every single second. In 2025 alone, 36 million new developers joined the platform, a 23% year-over-year increase. There are now 4.3 million AI-related repositories on GitHub, nearly double the number in 2023, and monthly contributions to AI projects reached approximately 6 million in August 2025, up 188% year over year. Nearly 80% of new developers on GitHub use GitHub Copilot within their first week.

Meanwhile, the Stack Overflow Developer Survey 2025 found that 84% of respondents are currently using or plan to use AI tools in their development work, up from 76% just a year earlier. Nearly half of all developers now use AI tools daily.

AI is already part of the workflow for the majority of people building technology.

But here’s the part that really matters: AI hasn’t just made developers more productive. It has dramatically expanded who can build in the first place.

A new kind of builder

Think about who else is building today, beyond traditional developers:

The product manager who spins up an AI agent to automate their team’s weekly reporting.
The marketing operations analyst who connects APIs through a workflow tool like Zapier without writing a single line of code.
The IT admin who builds a customer-facing chatbot using a low-code platform in an afternoon.
The entrepreneur who vibe-codes their MVP with the help of a large language model (LLM), deploying something that would have taken a full engineering team six months just five years ago.

These people are builders. They may not call themselves developers. They may not have a degree in computer science or formal education in software. But they are creating real, production-level experiences that real users depend on, and they deserve the same quality of advocacy and support that we’ve historically directed at developers.

HubSpot has begun distinguishing “builders” as a specific user persona: those who manage automations, middleware, and integrations, recognizing that the people building on their platform aren’t always traditional developers. AWS has long referred to its community as “builders,” a term that appears throughout their re:Invent programming, documentation, and community initiatives. Salesforce’s legendary Trailblazer community has expanded to embrace AI builders alongside traditional admins and developers as agentic AI becomes central to their platform. Google took this a step further in April 2026 by launching the Builders Hub through their Developer Program, even moving the URL to builders.google. Google is explicitly designed for “vibe coders, AI builders, and professional developers” alike. These are not coincidences. They are signals of a broader industry shift in how we think about the people who build with our platforms.

What builder advocacy means

With this name change, my team is committing — a commitment to showing up for all three types of builders we serve:

Developers: traditional coders, engineers, and architects who have always been our core audience. They’re not going anywhere, and neither is our dedication to them.
AI Builders: prompt engineers, LLM integrators, AI agent creators, and machine learning (ML) practitioners who are building the next generation of intelligent systems. This community is growing at a pace we’ve never seen before.
Automators: no-code and low-code builders who connect systems, design workflows, and create value without traditional programming. They are increasingly building mission-critical infrastructure, and they deserve advocacy, documentation, and tooling that treats them as first-class citizens.

With these name changes — from Developer Success to Builder Experience (BX), and from Developer Advocacy to Builder Advocacy — our team is saying clearly: We see all of you. We are here for all of you.

AI made its impact. It’s not going away

Some name changes are cosmetic. This one isn’t.

The community building with AI isn’t concentrated in a few zip codes anymore. It is global, diverse, and growing in ways that don’t fit neatly into the old categories.

The Stack Overflow Developer Survey 2025 found that 84% of developers are now using or planning to use AI tools. Among those using AI agents, roughly 70% say agents boosted their productivity and reduced task time. The tools are proving their value in the workflow, not just in the demo.

That’s the community I want to be part of. That’s the community I want to advocate for.

What’s next for builders

This name change is effective today, but it’s really the beginning of a larger journey. Our Builder Experience organization is investing in resources, content, and community programs that serve the full spectrum of builders: from the seasoned backend engineer to the AI tinkerer to the automation-first operator.

And here’s what hasn’t changed. You can still find us where you always have:

For documentation, visit our developer docs
For support, head to our developer forum
For helpful videos, visit our YouTube channel
On social media, follow us on our LinkedIn page

If you build — whatever that means to you — we’re here for you.

Welcome to Builder Advocacy.

Remember to follow us on X and subscribe to our YouTube channel for more exciting content. We also want to hear from you about the topics you’d like to see and any questions you may have. Leave us a comment below!

How Verifiable Digital Credentials Are Reshaping Trust Architecture

Mon, 29 Jun 2026 00:00:00 -0500

The identity stack is getting a new layer, and it’s already in your users’ pockets. Mobile driver’s licenses are live in dozens of U.S. states. The EU is mandating digital identity wallets for hundreds of millions of citizens. Apple Wallet and Google Wallet already hold government-issued credentials. Yet most development teams are not building for it.

The layer is called Verifiable Digital Credentials. The issuer infrastructure is already live, with wallets deployed and standards stable. The industry’s verifier-side adoption is still catching up, and that’s where we’re focusing our engineering work right now.

For years, when applications needed to verify a user’s age, license, or employment status, the default methods were document uploads, third-party verification APIs, and centralized storage of personally identifiable information (PII). It worked. But it accumulated cost at every step: data your infrastructure had to protect, compliance obligations that grew with every sensitive record, manual review queues that created friction, and third-party vendors holding your users’ identity data on your behalf.

VDCs replace that model. A trusted authority, such as a DMV, a university, or an employer, issues a cryptographically signed credential. The user holds it in a wallet. Your application requests the specific proof it needs. The credential validates itself. You record the outcome and move on. No document stored. No PII beyond what the transaction required. No third party in the middle.

The technical foundation relies on the Issuer-Holder-Verifier trust triangle: the Issuer signs the credential, the Holder stores it in a digital wallet, and the Verifier, your application, requests exactly the proof it needs. This model enables selective disclosure, where a verifier can confirm a person meets an age threshold without ever seeing their date of birth, home address, or a photo of their physical ID. By moving from document collection to claim validation, you eliminate manual review queues and dramatically reduce the personal data your infrastructure is obligated to protect.

This is not an incremental improvement on document uploads. It is a different architecture for how applications establish trust, one in which data collection is scoped to exactly what the transaction requires, and verification outcomes are separable from the identity artifacts that produced them.

The timing matters. The standards are mature. The wallets are deployed at scale. The trust ecosystems are live. What the ecosystem needs now is verifier-side applications that implement these flows well. That gap, between where the issuer infrastructure is and where verifier-side development is, is the opportunity in front of engineering teams right now.

Table of Contents

Authentication proves identity. Credentials prove claims.
The VDC standards stack: What you need to know before you build
Verification is not just a valid signature
Progressing beyond the Digital Credentials API to production VDC verification
Learn more about Verifiable Digital Credentials

Authentication proves identity. Credentials prove claims.

The most important distinction in the VDC space is also the most commonly missed.

Authentication answers one question: is this user the legitimate owner of this account? Verification answers a completely different question: can this person prove a specific attribute about themselves, their age, their license, their employment status, or their eligibility?

These are not the same problem. We have spent the last decade perfecting the art of logging users in (OpenID Connect, passkeys, strong MFA), but stretching your auth layer to carry verification responsibilities it was never designed for produces login flows that collect far more than they need to, and systems that are harder to evolve as both concerns grow independently.

The right architecture keeps them separate: authentication establishes the session, and VDC-based verification handles moments when a higher-trust signal is required.

In practice, those moments cluster around a recognizable set of product checkpoints: age gating for regulated goods, step-up verification before sensitive account actions, professional license checks, workforce credential validation, and high-value transactions. These are the natural insertion points for VDC-based verification. Not a replacement for your auth stack, but an additional layer, deployed precisely where the cost of a trust failure is highest.

The VDC standards stack: What you need to know before you build

VDCs are not a single specification. They are a layered ecosystem of interoperable standards, and understanding each layer is foundational to making good architectural decisions. The stack has three layers.

Credential Formats - defines what the credential is and how selective disclosure works. Two formats matter:

SD-JWT VC - selective disclosure built on JSON Web Tokens (JWTs) and developed in the IETF. This is the natural entry point for web and backend teams already working with JWT-based auth. The claims structure is familiar, and selective disclosure is native to the format. The right choice for enterprise credentials, age gating, employment and license verification.

mdoc (ISO 18013-5/7) - the format behind mobile driver’s licenses and government-issued digital IDs. A more tightly governed interoperability environment, stricter format expectations, and more prescribed wallet behavior. If your use case touches government-issued identity, this is your lane.

Protocols - define how credentials move between issuers, wallets, and verifiers. Two specs from the OpenID for Verifiable Credentials family handle both sides of the lifecycle:

OpenID4VCI governs issuance - how a wallet obtains a credential from an issuer. The issuer-side handshake. OpenID4VP governs presentation - how a wallet delivers proof of a claim to your application. It is credential-format-agnostic, supports redirect-based flows today, and supports the Digital Credentials API for web-native UX, where supported.

The W3C Digital Credentials API - the runtime layer that makes this usable in a browser. Its role is directly analogous to what WebAuthn does for passkeys: it standardizes how browsers invoke credential wallets, provides users proper consent context, and eliminates the custom URL scheme and deep-link hacks that make wallet invocation brittle today.

In simple terms: the Digital Credentials API invokes the wallet, OpenID4VCI and OpenID4VP manage the protocol flow, and SD-JWT VC or mdoc define the credential format. These layers are complementary, not interchangeable.

Verification is not just a valid signature

Verifying digital credentials requires more than cryptographic signature validation. A credential can have a mathematically valid signature and still be unacceptable in your application’s context. What determines acceptability is ecosystem trust.

Two concepts are non-negotiable in any verifier-side implementation:

Trust List - the curated set of issuers and signing keys your verifier accepts as authoritative. Think of it as conceptually equivalent to a browser’s root CA store. If the issuer is not on your trust list, the credential is invalid in your context regardless of signature validity.

Trust Framework - the policy and governance rules defining who can participate in the ecosystem and under what conditions. This is the legal and business contract behind the cryptography.

In the U.S. mDL ecosystem, for example, state DMVs publish their signing keys through the AAMVA Digital Trust Service, which serves as a trust anchor for Issuing Authority Certificate Authorities (IACAs). Your verification flow must integrate with that trust source and handle key rotation as issuers update their infrastructure. Build the trust framework integration as a first-class architectural requirement during implementation.

Progressing beyond the Digital Credentials API to production VDC verification

The browser rollout of native APIs is still progressing. Developers should not architect a flow that requires the Digital Credentials API as a hard dependency today. The most resilient path is to build on redirect-based OpenID4VP as your baseline; it works universally without specific browser dependencies, and then layer in the Digital Credentials API as a progressive enhancement to provide a first-class UX where supported.

The broader trends driving VDC adoption are not speculative. Government credential infrastructure is becoming a dependency layer on which developers can build. Data minimization is shifting from best practice to legal requirement as privacy regulations tighten globally. The auth and verification layers are separating permanently as both mature independently. Managed verification platforms are closing the tooling gap by abstracting away format handling, protocol flows, and trust-source integrations, so teams do not have to build every layer from scratch.

The practical path for engineering teams is incremental. Start with one verification moment in your product where the current approach creates measurable friction or accumulates unnecessary data liability. Define the minimum claim that moment actually requires. Keep it separate from your auth layer. Build something bounded. Learn from it. Expand.

The identity stack is getting a new layer. The developers who understand the formats, protocols, trust model, and browser reality are the ones who will architect what comes next. That window is open now, and the gap between where issuer infrastructure is and where verifier-side development is leaves real ground to gain for teams that move early.

The question for every senior engineer reading this is not whether VDCs are coming. They are already here. The question is whether your architecture is ready to meet them. Explore the VDC platform beta today.

Learn more about Verifiable Digital Credentials

If you’d like to explore the standards and ecosystem behind verifiable digital credentials in more detail, these resources are a good starting point.

Follow us on LinkedIn, Twitter, and subscribe to our YouTube channel to see more content like this. If you have any questions, please comment below!

Long Story Short: I Found My Place Between Code and Community

Wed, 24 Jun 2026 00:00:00 -0500

Taylor Swift once said, “Sometimes walking out is one thing that will find you the right thing.” That’s probably what happened to me. During my engineering days, all I ever wanted was to be a backend engineer, write code all day, use dark mode for IDEs, and sip coffee. And it all happened, I started as a software developer focused on shipping features, debugging all night, and building new features again. However, something felt incomplete, and being part of developer relations changed that.

From software developer to developer relations (DevRel): how it started

I was always an educator, into public speaking, and into building ideas and strategies. And as part of the Developer Relations team, I get to turn all that into work. Fortunately, I had the opportunity to wear multiple hats: community engineer, content creator, strategist, and workshop builder. And now I get to do code, community, and content, everything together.

What made me stay in the community was the feeling of “Oh, that’s exactly what I was looking for. Thank you for guiding me.” That sense of connection and appreciation motivates me, and I want to foster the same feeling in others. Once someone said this, and this became my calling. Hence, I enjoy being here, closer to the community.

My technical journey: Java, Spring Boot, and beyond

Over the years, I’ve written technical content, led hands-on workshops, produced YouTube videos, and contributed as a guest author and MongoDB Champion. My technical home base is Java, and frameworks like Quarkus and Spring Boot have always held a special place in my heart. And it’s been with me since my undergraduate days and has never left. Along the way in my engineering journey, another technology that prompted a deep dive was containers; topics such as Kubernetes, Docker, CI/CD, and GitOps all piqued my interest. I have since earned recognition as a MongoDB Champion for my contributions to the community over the years.

Why I’m joining Okta: identity, security, and AI

And now? I’m joining Okta. When I first thought about Okta, I thought of authentication, two-factor, and login flows. All important. But the more I dug in, the more I realized Okta is at the center of something much bigger. Identity is quietly becoming the foundation of how AI systems are trusted, accessed, and governed. That intersection of security, identity, and AI is where I want to be, and I couldn’t be more excited to explore it with all of you. While I am learning about Okta and its products, I am excited to discuss what the community is building with AI and Okta, and how we can help you on your journey.

Beyond my resume

When I’m not working on code or community projects, I’m at the gym. I’ve pursued this passion religiously for the past five years, always powering through my workouts with Taylor Swift tracks. I train hard, largely so I can enjoy all the desserts the world has to offer! I’ve fallen in love with weightlifting and am proud to say I can deadlift 200 lbs. Beyond the gym, I’m always chasing the perfect sunset and scouting for the next great sweet treat.

I am looking forward to building and breaking things on purpose. I’m excited to connect with you on LinkedIn and GitHub, and figure it all out together.

Remember to follow us on Twitter and subscribe to our YouTube channel for more exciting content. We also want to hear from you about the topics you’d like to see and any questions you may have. Leave us a comment below!

Okta Developer Connect San Francisco 2026 Recap

Tue, 09 Jun 2026 00:00:00 -0500

“Building an agent is only half the battle. Governing it is where we get stuck.”

That question came up in nearly every conversation we had with engineering managers leading up to Okta Developer Connect San Francisco. The second edition of our flagship developer event series brought more than 100 developers, architects, founders, platform engineers, and security leaders to Okta HQ on April 30 for an afternoon of technical sessions, hands-on labs, and community conversations on one theme: securing identity in the age of AI.

Unlocking AI in the enterprise: Okta for AI Agents is GA

The opening keynote made a point most enterprise teams are now grappling with. Identity has always been a security control. With AI agents in the picture, identity also becomes the governance layer for a class of workloads that didn’t exist a year ago: non-human, autonomous, and increasingly trusted to act on behalf of users.

The keynote also marked the general availability of Okta for AI Agents. The announcement framed the problem in terms that every security leader recognizes: once an agent ships, three questions arise almost immediately, and the product answers each.

Where are my agents? Discovery and onboarding work across frameworks, clouds, and SaaS environments, with shadow AI detection for the agents nobody officially registers.

What can they connect to? Protection rests on short-lived credentials, scoped tokens, vaulted secrets, and access controls that extend to Model Context Protocol (MCP) servers.

What can they do? Governance covers the full lifecycle: access requests, certification, audit logs that stream to Security Information and Event Management (SIEM) platforms, and a kill switch that deactivates an agent that goes off-script.

For the developers and architects in the room, the announcement set the tone for the rest of the day. Every session that followed answered one of those three questions in some way. You can dig deeper on the Okta for AI Agents product page or in the documentation.

Why this conversation matters now

Across the sessions and the AI Interview activation we ran throughout the event, one theme kept coming up: agents are arriving in production faster than most teams can govern them.

Developers told us they have shifted from writing every line of code to reviewing, guiding, and orchestrating AI-generated work. Engineering teams are connecting agents to internal APIs, retrieval-augmented generation (RAG) pipelines, MCP servers, and third-party tools. Security and IAM leaders are watching it happen and asking how to apply the principles they already trust (least privilege, scoped access, auditability) to identities they didn’t anticipate when they built those controls.

A few patterns stood out from those conversations.

Agents are outpacing governance. Many teams ship an agent in days. Wrapping it in policy, access reviews, and lifecycle controls takes weeks or months. The gap between “it works” and “it’s safe to leave running” is where most of the risk lives.

Static credentials are the new shadow IT. Hardcoded keys, long-lived tokens, and shared service accounts are how a lot of agents reach data today. They make the demo work. They also make incidents harder to scope when something goes wrong.

RAG has a permissions problem. Retrieval-augmented generation is now the default pattern for enterprise AI. The hard part is making sure an agent retrieving documents on behalf of a user only sees what that user can access at the data layer, and not just the prompt.

Non-human identity is a real category. Teams that already invested in human identity governance now realize they need an equivalent practice for agents, bots, and workloads. Naming them, owning them, and decommissioning them are no longer optional.

Cross App Access and the protocol behind it

Cross App Access (XAA) drew one of the most-attended sessions of the day, and for good reason. As agents move between applications, the consent model designed for users clicking buttons doesn’t hold up. Repeated prompts get fatigue clicks. Unmanaged app-to-app connections become invisible to security teams. Long-lived tokens leak.

XAA introduces a model in which the enterprise identity provider mediates access between applications based on policy, rather than relying on per-user consent or app-to-app integrations. The session grounded the protocol in the OAuth context most developers already know, which made the new pieces (identity assertion and token exchange across app boundaries) easier to place.

For developers, the practical takeaway is clear. If you’re building an application that needs to act on behalf of a user inside another application, the question is no longer “how do I get a token?” It’s “how does my organization want to govern this access, and how does my app respect that policy?”

A hands-on walkthrough of xaa.dev gave attendees a chance to step through the Cross App Access flow on their own laptops. Watching identity assertion and token exchange move across a requesting app, an identity provider, and a resource app turned an otherwise dense protocol into something concrete. It gave the room a working mental model to take back to their own architectures.

Securing AI agents with Auth0

A dedicated session walked through the identity patterns developers can adopt today when building AI applications. The framing stayed deliberately practical, organized around the four risks that show up most often when an agent starts touching real data: authenticating the user the agent acts for so context stays in the chain; using a Token Vault so agents don’t handle long-lived third-party credentials directly; asynchronous authorization so users can approve sensitive actions out of band; and fine-grained authorization so an agent only retrieves the data and triggers the actions a user can access.

The session landed because these patterns map naturally to OAuth concepts most developers already know. The work isn’t learning a new identity model from scratch. It’s applying delegation, scoped tokens, and policy-driven authorization to a new kind of caller, one that doesn’t have a browser, doesn’t click “allow,” and doesn’t stop to think before acting. Explore the patterns and SDKs in Auth0 for AI Agents.

The panel: What teams are actually asking about AI agents

The panel pulled the conversation out of theory and into the questions teams are wrestling with right now. An opening icebreaker about what an unsecured personal AI agent might buy if it went rogue set the tone: practical, direct, and sometimes intentionally playful.

When applications already have their own access controls, does identity get the final say, or does the application remain the real gatekeeper? How do you stop MCP servers from quietly becoming a backdoor into enterprise data? Which authentication mistakes do developers most often make when they build their first agent? How do teams move from identity as an audit log they review after the fact to identity as a guardrail that enforces decisions in real time?

The panel didn’t offer easy answers, and that was the point. Securing AI agents isn’t a feature you add at the end of a build. It’s a set of decisions about delegation, consent, and least privilege you need to make early, before you connect the agent to anything that matters.

What this means for builders

A few takeaways from the day are worth carrying forward:

Treat agents as identities, not features. The moment an agent can act on data or trigger workflows, it needs the same lifecycle treatment as a user account: ownership, scope, review, and revocation. Naming it after the application isn’t enough.

Design the consent model before the integration. It’s much easier to decide who can delegate what, and how that delegation expires, before you connect an agent to a calendar, a CRM, or a document store. Once the integration goes live, every change becomes a migration.

Push authorization closer to the data. Fine-grained authorization works best at the layer where decisions actually happen: the database, the vector store, the API. Token-level scopes alone don’t stop a RAG pipeline from surfacing documents outside the user’s permissions.

Plan for the agent you haven’t built yet. Most teams plan to deploy more agents next year than they did this year. The patterns that feel optional today - discovery, governance, scoped credentials become foundational the moment you have a fleet to manage.

Community, Conversations, and the AI interview activation

Beyond the sessions, the energy in the room was the hardest part to put on a slide. Attendees stayed for the hands-on lab, joined the AI Interview activation, asked sharp questions during the panel, and kept the conversation going with Okta and Auth0 engineers, product leaders, and developer advocates well past the formal close.

The AI Interview activation in particular created a useful feedback loop. Developers told us how AI is reshaping their day, not in marketing terms, but in the specifics of how they review pull requests, find documentation, and decide when to trust an AI-generated answer. Those conversations are already shaping what we build and what we write next.

What comes next

Okta Developer Connect started as a forum for the conversations that are harder to have on a webinar, the ones where developers and architects can push back, ask the awkward question, and leave with something they can actually use. The San Francisco edition continued that mission with a sharper focus on AI agents, OAuth, Cross App Access, and the identity patterns shaping the next generation of applications.

If a single thread ran through the day, it was this: the teams that treat identity as part of the agent, not a wrapper around it, ship at the speed the business asks for, without trading away the controls that keep them safe.

Thank you to everyone who joined us in San Francisco, asked the harder questions, and shared what you’re building. We’re looking forward to the next edition.

Stay tuned for upcoming Okta Developer Connect events, and follow OktaDev on LinkedIn, X, and YouTube for new tutorials, videos, and announcements.

The One Where I Found My Way to DevRel

Fri, 05 Jun 2026 00:00:00 -0500

If you’ve watched Friends, you’ll know that life rarely goes according to plan. One day, you’re helping a friend move a couch while yelling “Pivot!”, and the next, you’re wondering how you ended up there in the first place.

My career has felt a little like that.

Growing up, I was always drawn to creative pursuits. You could usually find me with a book in hand, experimenting with calligraphy, sketching something random, writing poetry, baking a new dessert, or trying out a recipe I found somewhere online. Technology wasn’t the obvious destination (even though I love building!), storytelling was.

That love for explaining things eventually led me into technical writing.

Building docs for developers

I started working with startups, creating everything from API documentation and user guides to onboarding content and developer-facing resources. I loved the challenge of taking something complex and making it easier to understand. There was something deeply satisfying about helping someone go from “What does this even mean?” to “Oh, now I get it.”

For a while, I thought documentation was the destination. Plot twist! It wasn’t.

When I joined JDoodle (a web-based IDE), I found myself spending more time talking to developers. I wasn’t just writing for them anymore. I was listening to them, learning how they built things, understanding their frustrations, and seeing firsthand what made them excited about technology.

The more conversations I had, the more I realized something. The thing I enjoyed most wasn’t just creating documentation. It was connecting with people.

Finding my place in devrel

I started attending developer events and conferences. Then came product demos. Then booth duty. Then community conversations. Then hackathons. Then organizing internal events.

Somewhere along the way, what started as “I need to understand developers better so I can write better documentation” turned into “I genuinely love being part of developer communities.”

I discovered that my favorite moments weren’t necessarily publishing a new document or updating an API reference.

They were moments like:

Watching a developer finally solve a problem after a conversation.
Seeing people get excited during a product demo.
Helping organize hackathons where creativity and technology collide.
Meeting builders who were passionate about bringing their ideas to life.
Learning something new from every event I attended.

As it turns out, the skills that drew me to writing in the first place translated surprisingly well into developer advocacy.

At their core, documentation and developer advocacy are both about empathy. They require understanding your audience, telling clear stories, and helping people succeed.

Joining the Okta community

Looking back, it makes perfect sense. The person who loved books, writing, art, and storytelling didn’t leave those interests behind when entering tech. She simply found a new audience.

Today, I’m incredibly excited to continue that journey at Okta.

I’ll be working alongside developers, creators, builders, and community members who are shaping the future of identity and security. I’m looking forward to learning, sharing, creating content, attending events, and most importantly, connecting with the people who make this community so special.

As Phil Dunphy said, “When life gives you lemonade, make lemons. Life will be all like, ‘What?!’” My career may not have followed a traditional path, but somehow it led me exactly where I wanted to be.

I’m excited to meet all of you. If you see me at an event, or find me on socials, come say hello. I’d love to hear what you’re building.

Okta Developer

Introducing Okta Journeys: A Better Way for Developers to Learn Identity

What are Okta Journeys for developers?

Learn identity foundations

Plan your customer identity implementation

Build and implement identity solutions

Six Okta Journeys available now

What’s next: Okta for AI agents and more

Tell us what you think

How to Build and List Secure Cross App Access (XAA) Connections on Okta Integration Network (OIN)

What is Cross App Access (XAA)?

Why Cross App Access (XAA) matters for ISVs and their customers

Prerequisites for supporting Cross App Access (XAA) in your app

Implementation and testing guide for Cross App Access (XAA) with Okta as IdP

Getting listed in the Okta Integration Network (OIN)

XAA enablement questionnaire

What happens next after you submit your OIN and XAA request?

Need help with your Cross App Access (XAA) submission?

Learn more about Cross App Access and the Okta Integration Network

Enabling Cross App Access for SAML-Based Enterprise Apps

How XAA in SAML works

Analyzing the ID-JAG claims

XAA implementation checklist for SAML-federated applications

Mapping user identity in the SAML NameID attribute

Validating the ID-JAG and resolving the user

Issuing the access token

Updating authorization server metadata

Making cross-application requests from your SAML app securely

Configure your XAA SAML App in Okta

Create the SAML 2.0 app in Okta

Register and configure the AI Agent in Okta

Verify your Okta XAA setup on xaa.dev

Configure SAML SSO

Confirm the SAML Assertion exchange for a refresh token

Verify the refresh token exchange for an ID-JAG token

Redeem the ID-JAG for an access token at the resource authorization server

Call the resource API with the access token

Prove the XAA connection end-to-end

Takeaways for implementors who have both OIDC and SAML apps

Learn more about Cross App Access, SAML, and OAuth 2.0

The Builder Revolution: Why We're Shifting to Builder Advocacy

The builder revolution is already here

A new kind of builder

What builder advocacy means

AI made its impact. It’s not going away

What’s next for builders

How Verifiable Digital Credentials Are Reshaping Trust Architecture

Authentication proves identity. Credentials prove claims.

The VDC standards stack: What you need to know before you build

Verification is not just a valid signature

Progressing beyond the Digital Credentials API to production VDC verification

Learn more about Verifiable Digital Credentials

Long Story Short: I Found My Place Between Code and Community

From software developer to developer relations (DevRel): how it started

My technical journey: Java, Spring Boot, and beyond

Why I’m joining Okta: identity, security, and AI

Beyond my resume

Okta Developer Connect San Francisco 2026 Recap

Unlocking AI in the enterprise: Okta for AI Agents is GA

Why this conversation matters now

Cross App Access and the protocol behind it

Securing AI agents with Auth0

The panel: What teams are actually asking about AI agents

What this means for builders

Community, Conversations, and the AI interview activation

What comes next

The One Where I Found My Way to DevRel

Building docs for developers

Finding my place in devrel

Joining the Okta community

Mapping user identity in the SAML `NameID` attribute