It's our first Launch Week of the year, and we're so excited to share our latest innovations for Okta to help you make your agentic future a reality without compromising security. This launch brings powerful updates across the Okta Platforms, and gives you the tools and information you need to move your AI environment from "unknown and controlled" to verified and governed by asking three important questions: Where are my agents? What can they connect to? What can they do?

Dive in to discover how Okta is closing the AI identity gap. Read more here.

👉 We’d love to hear what you think! What feature are you most excited about? Got questions about any of the new capabilities? Post them below, and we’ll do our best to connect you with the right product experts.

Hi everyone,

I’m setting up Okta Advanced Server Access (ASA) to manage Windows and Linux server access using Okta groups and ASA projects. I created an Okta group (for example windows-admin) and added users to it. However, when I try to add this group to an ASA project (ASA → Projects → Groups → Add Group), the group doesn’t show up at all. What I noticed later is that the group only becomes visible in ASA after I assign it to the “Advanced Server Access” application under Applications → Advanced Server Access → Assignments. Without this step, ASA behaves as if the group doesn’t exist.

My questions:

1. Is assigning the group to the ASA application a mandatory step for it to appear in ASA projects?
2. Is this the expected / recommended way to manage ASA users with Okta-native groups?
3. Is this behavior the same on the Integrator Free Plan?
4. Just trying to understand if this is by design or if I’m missing something obvious.

TIA

Hi Okta Support Center Team, I’m currently working on integrating a Node.js web application with Okta (OIDC Web App) and I’m stuck on an access issue.

Even after assigning Super Admin, API Administrator, and Application Administrator roles to my secondary Okta user, I still receive the following error when trying to log in through the OIDC flow:

I’ve verified the following:

1. The OIDC application is created correctly

2. Policies and sign-on rules are configured

3. Ports, redirect URIs, and Docker setup are updated

4. Both users exist and are active

5. Admin roles are assigned properly

But the issue persists, and it seems to be related to app access or assignment.

If anyone has worked with Okta OIDC policies or application access rules and can help me understand what I might be missing, I would really appreciate your guidance. I attached my Linked In post URL below for your reference.

https://www.linkedin.com/posts/tamiri-ram-kumar-devopsengineer_okta-oidc-authentication-activity-7402947338727587840-TKoF?utm_source=share&utm_medium=member_desktop&rcm=ACoAAB-WpooB0zqk87UEpYLOrXKrZAeZIe9mDxs

Hi everyone!

It’s Mid-Year Launch Week at Okta, and we’re excited to roll out a fresh wave of innovations designed to help you protect every identity — from human to non-human, to AI agent. You can check out the full overview of what’s new across the platform by reading this blog post.

For those of you specifically interested in Okta Privileged Access, we’re especially excited about a major new enhancement: Active Accounts.

With Active Accounts, you can now:

✅ Discover unmanaged privileged accounts across your environment

✅ Create targeted access policies for better control

✅ Automate credential rotation

✅ Audit user activity with greater visibility

Read all about it here.

Let us know what you think, or drop your questions in the thread and we'd be happy to connect you with the product team if you want to learn more!

Okta Launch Week 2025 is here!

Check out our latest corporate blog post for an inside look at the newest advancements in Identity Security, unveiled during Launch Week. As cyberthreats evolve, Okta continues to lead the charge in delivering seamless, secure access management solutions. Explore how our latest updates are empowering organizations to stay ahead of threats while securing workforce, customer, and AI-driven systems. Dive in to discover how Okta is shaping the future of Identity Security.

We'd love to hear what excites you most about these new innovations! How do you think they’ll enhance your day-to-day? Drop a comment in the discussion post and let us know!

Has anyone been successfully in getting a more traditional SSH configuration with SSSD and LDAP working along with an Okta PAM agent on Linux? I have a use case where I need both, one to support my legacy solutions as well as enable better administrative control through PAM.

I've configured 2 sshd services, port 22 for traditional and port 222 for Okta PAM specific, updated the PID for the additional sshd-oktapam, separate sshd_config file, configured sftd agent to use that port and ssh config. I get sporadic results for the sftd connection, sometimes it works sometimes its really slow (e.g. 2 min to establish shell session), and other times it kicks me off the session at connection or shortly thereafter.

There seems to be a conflict between sftd, sshd, sssd, pam or something else related in the auth mechanisms in Linux if Okta PAM isn't the only method for connection.