• Public

Okta Privileged Access

Skip Feed

    • Mihai N. (Okta, Inc.)

      Hi @avshch (BCRC)​ , Thank you for reaching out to the Okta Community! 

       

      I ran this by some of my OPA colleagues and they mentioned three different credential management modes available in Okta Privileged Access, depending on how tightly integrated the target application is with OPA:

       

      Option 1: Connected SaaS Application

      A "connected" SaaS application is one where Okta Privileged Access has a direct API integration with the cloud service. In this mode, OPA cannot only store the privileged credentials but also automatically rotate them on a scheduled basis. For example, if you have a connected integration with Google Workspace, OPA can periodically change the admin account password and update it in the vault without any manual intervention. This provides the highest security posture because credentials are never static. They change regularly, reducing the window of exposure if a credential is compromised.

       

      Option 2: Disconnected SaaS Application

      A "disconnected" SaaS application is one where OPA does not have a direct API integration. In this case, OPA cannot automatically rotate the password because it has no way to communicate with the application to change it. However, OPA still provides value by securely storing the credential and offering a built-in random password generator. When you need to update the password, you would manually change it in the target application (e.g., Google Workspace admin console) and then update the stored credential in OPA. OPA ensures the credential is encrypted at rest and access to it is logged and audited.

       

      Option 3: Static Secrets

      Static Secrets is OPA's credential vault feature for storing any sensitive value that doesn't fit the traditional username/password model (such as API keys, service account keys, SSH keys, database connection strings, or OAuth tokens). These secrets are securely encrypted and stored in OPA's vault. Access is controlled through policies, and all retrieval and usage is audited. Unlike connected applications, there is no automatic rotation; the secret remains static until you manually update it.

       

      In short:

      • Connected SaaS: Automatic password rotation + secure storage + audit trail
      • Disconnected SaaS: Manual password management + secure storage + random password generator + audit trail
      • Static Secrets: Secure storage of any credential type (keys, tokens, etc.) + audit trail, no rotation

      The choice depends on whether the application supports OPA's API integration, and what type of credential you're managing.

       

      If you are interested in specifics for your use case, please open a case to discuss the implementation directly with my SME colleagues. 

       

       

      Regards.

      --

      Help others in the community by liking or hitting Select as Best if this response helped you.

      Collect them all. Learn a new skill and earn a new Okta Learning badge.

      Just released: More Okta Community badges just added

      Expand Post

  2. Christina.J (Okta)

    Edited March 16, 2026 at 6:52 PM

    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.

    Expand Post
    • 84 views
    Paul S. and Mihai N. like this.

  3. KalpanaS.31393 (Customer)

    February 10, 2026 at 7:25 AM

    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

    Expand Post
    • 1 comment
    • 92 views

    • Paul S. (Okta, Inc.)

      Hello @KalpanaS.31393 (Customer)​ Thank you for posting on our Community page!

       

      This is all expected

      1 it is not mandatory, you can assign the users individually and use group push to push the group membership

      2 It is expected, recommended? It depends on the use case.

      3 This behavior is the same for any Okta application that uses provisioning and group push, this is not unique to ASA.

      You will have to just created a group in Okta initially. How would ASA or any app know about it ? Apps does not pull all the groups from IDP unless provisioned through group push

       

      Thank you for reaching out to our Community and have a great day!

      --

      Help others in the community by liking or hitting Select as Best if this response helped you.

      Expand Post

  4. RamS.22711 (Customer)

    December 6, 2025 at 6:36 AM

    Screenshot 2025-12-06 at 11.12.02Hi 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:

     

    Screenshot 2025-12-06 at 11.15.02

    Image is not available
    Screenshot 2025-12-06 at 09.58.07

     

    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

    Expand Post

    #okta #oidc #authentication #devops #nodejs #sso #identityaccessmanagement #iam #websecurity #cloudsecurity #accesscontrol #techcommunity #developers #authintegration | Tamiri Ram Kumar

    Hi Everyone, 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: ⚠️🔴 “You are not allowed to access this app. To request access, contact an admin.” 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 Okta Okta/Entra ID Training Project Support Okta Community Okta Alumni Community Rapyder Cloud Solutions DevOps Learner Community Tamiri Ram Kumar #Okta #OIDC #Authentication #DevOps #NodeJS #SSO #IdentityAccessManagement #IAM #WebSecurity #CloudSecurity #AccessControl #TechCommunity #Developers #AuthIntegration

    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

    • 1 comment
    • 100 views

    • Paul S. (Okta, Inc.)

      Hello @RamS.22711 (Customer)​ Thank you for posting on our Community page!

       

      This question is more appropriate for our dedicated Okta Developer Forum.

      My advice would be to reach out via devforum.okta.com to take advantage of their expertise.

      While we'll do our best to answer all of your questions here, this medium is more inclined towards Okta core products and features (non-developer work).

       

      Thank you for reaching out to our Community and have a great day!

      --

      Help others in the community by liking or hitting Select as Best if this response helped you.

      Expand Post

  5. User16370330549592969269 (Customer Support Online Experience)

    June 24, 2025 at 10:30 PM

    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!

    Expand Post
    • 123 views
    ryhf4 likes this.

  6. User16370330549592969269 (Customer Support Online Experience)

    April 9, 2025 at 9:06 PM

    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!

     

    Expand Post
    • 177 views
    ryhf4 likes this.

  7. AaronG.62630 (Customer)

    March 20, 2025 at 8:07 PM

    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.

    Expand Post
    • 1 comment
    • 135 views

    • Mihai N. (Okta, Inc.)

      Hi @AaronG.62630 (Customer)​ , Thank you for reaching out to the Okta Community! 

       

      While this is not my area of expertise, I ran this by my PAM colleagues and they mentioned that you will need to make sure the username format is different as mentioned in this article. The article is for ASA but applies to OPA as well. We will get it updated.  

      Also, while I was looking into this it came to my attention that you have a support ticket open as well, so I recommend continuing the discussion with the Support Engineer.  

       

       

       

      Regards.

      --

      Help others in the community by liking or hitting Select as Best if this response helped you.

      Level up your Identity security superpowers with Okta Learning.

      Join the Online Discussion for Ask me Anything on March 25, 2025: Identity Threat Protection with Okta AI

      Expand Post

    • Mihai N. (Okta, Inc.)

      Hi @AbbyG.46006 (Customer)​ , Thank you for reaching out to the Okta Community! 

       

      You can get started here. 

      Make sure to check out Requirements and limitations as well, and check with your Okta Account Executive to see if your tenant has the required features and entitlements. 

       

       

       

      Regards.

      --

      The new Okta Help Center YouTube channel is your go-to resource for tips, troubleshooting, and best practice videos. Subscribe today.

      Expand Post

End of Feed
8 Chatter Feed Items

Group Details

Details

Description
Welcome to the Okta Privileged Access discussion group. This group is an open community for Okta Privileged Access customers to collaborate, share experiences, tackle common use cases, and keep up to date on product releases. Help grow the community by submitting topics for discussion or by bringing your expertise to the comment sections.
Show More
Information
Member Count
26 Members
Owner
Rajesh Kumar