Argo CD SSO with Okta: OIDC setup and group roles

How Argo CD SSO with Okta works and which method to choose

If you need Okta sign-in and group-based access for an Argo CD installation, the supported path is direct OIDC against a custom Okta authorization server that returns a groups claim, with a separate single-page app for CLI login. SAML through Dex is the fallback when the groups claim cannot be returned. Choose the direct OIDC path first, because it keeps Okta as the identity provider without adding Dex as a second authentication layer to operate and upgrade. The groups claim is the decision point. The Argo CD Okta guide says returning the groups scope requires Okta's API Access Management add-on. That add-on is free on the developer edition but is a paid add-on in production, so confirm with your Okta account team whether your production tenant already includes it before you design around groups. Okta's pricing page places API Access Management in the Enterprise suite, so ask which suite and contract your organization holds and whether the add-on is part of it.

Before you pick a method, check three things in your own tenant: whether API Access Management is licensed, which Okta group names your admins and read-only users belong to, and whether your Argo CD version supports the Okta method you plan to use. Confirm the group claim with a test user first, because a mapping that works for one group can still fail if the claim is filtered or renamed. If groups cannot be delivered, plan for SAML through Dex and accept the extra component that brings.

What you need in Okta and in the cluster before configuring Argo CD

Most delays in an Okta integration come from entitlements and cluster settings confirmed too late. The cards below cover the Okta licensing and admin access, the Argo CD version and deployment shape, the URL and TLS, and the CLI callback that connect the two sides.

Confirm the Okta edition and add-on

Returning a groups claim through a custom authorization server depends on Okta's API Access Management capability. The Argo CD Okta guide says this add-on is free on a developer edition but is a paid add-on in production. Ask your Okta account team whether your current suite includes it, because the Okta pricing page places API Access Management in the Enterprise suite. If it is missing, plan the SAML fallback through Dex before you start.

Admin rights to build the Okta objects

The person configuring Okta needs rights to create a custom authorization server, a scope and claim for groups, an access policy assigned to the web app, and two applications: a web app for the Argo CD server and a separate single-page app for CLI login. Confirm this access before the change window, and record who owns the Okta configuration afterward so later changes to group names or policies do not break sign-in.

Argo CD version and supported patch line

Choose a minor version that still receives patch releases. The release process states that only the three most recent minor versions get patches, and the GitHub releases page lists current patch lines. Check the OIDC and CLI behavior for your chosen version, because login flows changed across releases. Also review the 2.14 to 3.0 upgrade notes if you are migrating an older installation, since RBAC and repository configuration changed there.

HA or single-replica deployment choice

A single replica is acceptable for a lab, but production usually needs the HA manifests, which require at least three nodes because of pod anti-affinity rules. The SSO settings live in the same Argo CD configuration either way, so decide the topology first. Confirm your cluster has three schedulable nodes, that IPv6-only clusters are not in use, and that your team can restart Argo CD during the configuration change.

Argo CD URL, DNS and TLS

The URL configured in Argo CD becomes the OIDC redirect base, so it must resolve from user workstations and match what Okta holds. Set a stable hostname, issue a certificate your browsers and the CLI trust, and confirm that any internal certificate authority is trusted by the Argo CD components that reach Okta. A changed hostname later means updating both Okta applications and the Argo CD settings together.

Localhost:8085 callback for CLI login

The argocd CLI completes argocd login --sso by opening a local listener on port 8085. Your Okta single-page app must allow redirect URIs for localhost:8085, and engineers' workstations must allow that port. Corporate endpoint controls or a port already in use will break CLI login even when the browser flow works. Test the CLI from a managed laptop before you tell users the migration is complete.

Configuring Okta and Argo CD in sequence

This sequence connects Argo CD to an Okta custom authorization server so that sign-in works in the web UI and the CLI, and group membership in Okta drives Argo CD roles. Each step ends with a check you can run before moving on.

Create the custom authorization server and groups claim
An Okta administrator creates a custom authorization server in the Okta Admin Console, adds a scope named groups, and adds a claim that returns the user's group membership in the ID token. Returning the groups scope depends on Okta's API Access Management capability, which the Argo CD Okta guidance says is free on a developer edition but a paid add-on in production, so confirm licensing with Okta before you build. Done means the server's metadata URL resolves and a test token request returns a groups claim for a user who belongs to a group. If the claim is missing, check the claim filter and the group membership before changing Argo CD.
Assign an access policy to the web app
Still in the authorization server, the administrator creates an access policy and a rule that allows the Argo CD web application to request tokens with the openid, profile, email and groups scopes. Without a policy assigned to the app, Okta does not issue tokens from this server to Argo CD even when the server and claim exist. Verify the policy by requesting a token for a test user in the web app context and confirming the token contains the expected audience and the groups claim. Record the issuer URL and the client ID for the next step.
Register the web app and its redirect URI
The administrator creates an OIDC web application in Okta for Argo CD, sets the sign-in redirect URI to the Argo CD callback path on your Argo CD hostname (for example, illustrative), and generates a client secret that is stored in a Kubernetes Secret rather than in Git. Confirm the hostname matches the external URL you set for Argo CD, because a mismatch is the most common cause of redirect errors at sign-in. Done means the application appears in Okta with its client ID, client secret and the redirect URI listed, and the Argo CD team can read the secret from the cluster.
Create the separate CLI single-page app
The administrator creates a second application of type single-page app for the argocd command-line client. Its redirect URIs must include the localhost callback addresses on port 8085, which the Argo CD Okta guidance specifies for CLI login. Keep this app separate from the web app so its client ID can be set independently in Argo CD. Verify by listing the application's redirect URIs and confirming the localhost entries are present exactly as the guide describes, and that the app is assigned to the same users or groups as the web app.
Set oidc.config and the CLI client ID in argocd-cm
A platform engineer edits the argocd-cm ConfigMap in the Argo CD namespace to set the url to your Argo CD hostname, and the oidc.config block to the Okta issuer URL, the web app client ID, the client secret reference, and the requested scopes including groups. The CLI client ID is set in the same configuration through the cliClientID setting, as the Argo CD Okta guidance describes. Apply the change, restart the Argo CD server if your version requires it, and open the web UI. Done means the login page shows a Log in via Okta option and sign-in completes without a certificate or redirect error.
Map Okta groups to Argo CD roles in RBAC
The platform engineer adds policy lines to argocd-rbac-cm that bind the groups claim values to Argo CD roles, using the group names or IDs that Okta actually returns in the token. The scopes setting in the RBAC ConfigMap must list groups so Argo CD reads the claim. Start with a read-only role for a test group, then add project-level permissions after the test passes. Verify with argocd account get-user-info after signing in as a test user, which shows the groups and effective roles Argo CD sees. If the group does not appear, the claim value or the scopes setting is the likely cause.
Confirm CLI sign-in and disable the admin account
Run argocd login with the --sso flag against your Argo CD server and confirm the browser flow completes through Okta and returns a session in the terminal. Then test that a user outside the mapped groups is denied the expected actions. Once SSO works for administrators, the Argo CD user management guidance recommends disabling the built-in admin user by setting admin.enabled to false in argocd-cm. Keep a documented break-glass procedure before you disable it, and confirm that at least one mapped administrator can sign in before the change is applied.

How the login and group claim flow between Okta and Argo CD

The point to plan for is that Argo CD never sees Okta credentials. When a user opens the Argo CD web UI and chooses SSO, the browser is redirected to the Okta custom authorization server you configured, the user authenticates there (including any multi-factor policy Okta enforces), and Okta redirects back to the Argo CD callback with an authorization code. Argo CD exchanges that code for tokens and reads the ID token. For group-based access, the ID token must contain a groups claim, and Argo CD then matches each group value against the g lines in policy.csv to decide which p permissions apply. Group names in the claim must match the strings in policy.csv exactly, so confirm the claim values with a test user before you write any role mappings.

Argo CD also authenticates its own API requests only with JSON Web Tokens, so the groups claim has to survive into the session token that Argo CD issues and validates, not just sit in the Okta token. Check that the scopes setting in the OIDC configuration requests the groups scope, and that the access policy on the web app allows it. If the claim is missing, the user will sign in successfully but receive no project or role permissions, which is the failure mode most teams see first. Use a non-admin test account to confirm that the expected role appears in the UI and the API before you disable the built-in admin user.

The CLI follows a separate path. argocd login --sso opens a browser against a second Okta application, a single-page app with localhost:8085 redirect URIs, so the CLI never shares the web app's client secret. The browser flow ends at a local callback on the engineer's machine, which hands the token back to the CLI. Because this client is separate, it needs its own access policy and its own sign-in and sign-out settings, and a change to the web app does not fix a CLI redirect error. Treat the two applications as a pair in your change records and test both paths after any Okta configuration change.

Choosing between direct OIDC and SAML through Dex

Direct OIDC is the simpler path when your Okta organization can return a groups claim. Argo CD talks to a custom authorization server in Okta directly, with no Dex component in between. Group membership arrives in the ID token, and the RBAC mapping in Argo CD reads that claim to assign roles. The Argo CD Okta guide describes this model and requires a groups scope and claim on the authorization server, an access policy assigned to the web app, and a separate single-page app for CLI login.

Fewer moving parts: Argo CD authenticates against Okta without running Dex, so there is one identity path to monitor and upgrade.
Groups scope dependency: Returning the groups scope depends on Okta's API Access Management capability, which the Okta pricing page places in the Enterprise suite.
Group claim contents: The groups you emit become the subjects you map in policy.csv, so decide early whether you map group names or IDs.
Separate CLI client: argocd login --sso needs its own Okta client with localhost redirect URIs, which adds an application to manage.
Dependency on Okta configuration: Changes to the authorization server, claims or access policies can break sign-in for every user at once.

Confirm the groups claim name and token contents against the Argo CD Okta guide for your Argo CD version before committing to this path.

Mapping Okta attributes and groups to Argo CD roles

This table lists the Okta claim, the Argo CD settings and the RBAC policy lines that turn Okta group membership into Argo CD permissions. Read it in configuration order, because each step depends on the groups claim arriving intact. The main takeaway is that group values must match exactly, so confirm the claim format in your own Okta tenant before writing policy.

Item	Setting or behavior	What to confirm
Okta groups claim	Returned through a groups scope and claim on the custom authorization server, using the access policy assigned to the Argo CD web app	Claim name, value filter and that the access policy applies to the web app
Scopes setting	The requested scopes in the OIDC configuration must include the groups scope so Argo CD asks for the claim	Scope name matches the authorization server exactly, including case
Group values: names or IDs	Argo CD compares the string the claim carries with the group value in policy.csv, so the form Okta emits sets the policy text	Whether your tenant emits group names or IDs, and that the strings match character for character
Group lines in policy.csv	A g line binds a group value to a role, such as an admin or read-only role, for every member of that group	Each group value exists in Okta and appears in the claim for a test user
Project roles bound to groups	p lines grant permissions on a project to a role, and g lines can bind an Okta group to that project role	Project and role names exist in Argo CD before the binding is added
User identifier for RBAC	User-level policy lines use the identifier Argo CD receives from the token, while group lines use the groups claim	Which claim Argo CD sees in a test login; for Dex-based setups the 3.0 upgrade notes name federated_claims.user_id
Default role	policy.default sets what authenticated users get when no group matches; leaving it empty grants no access	Choose the default deliberately and avoid a broad default for Okta users with no mapped group
Admin account	The built-in admin user is meant for initial setup and should be disabled with admin.enabled set to false once SSO works	A mapped admin group has been tested and a recovery path is documented before the built-in account is disabled

Hardening the Okta integration for production

Getting Okta sign-in working is only the first step. The controls below decide who can reach Argo CD, what they can change once inside, and how well the credentials behind the integration are protected. Each one is a decision you make and a check you repeat after every change to the Okta app or the Argo CD configuration.

Disable the built-in admin user

Argo CD's user management documentation recommends using the built-in admin account only for initial setup. Once Okta sign-in and at least one tested admin role work, set admin.enabled to false in the argocd-cm ConfigMap. Confirm that a named Okta administrator can still reach the UI and CLI before you disable the account, and keep a documented break-glass procedure in case the identity provider is unavailable.

Assign only the groups that need access

In Okta, the Argo CD application should be assigned only to the groups that need to sign in. Anyone who is not assigned gets no token, so this limits the population before RBAC applies at all. Review assignments on a fixed schedule and remove groups that no longer map to an Argo CD role, since a stale assignment grants sign-in to people who should no longer have it.

Protect the OIDC client secret

The client secret for the Okta web app should live in a Kubernetes Secret, not in the Argo CD ConfigMap or in Git. Restrict read access to the Argo CD namespace with RBAC, and enable encryption at rest for etcd or your managed cluster's equivalent. Rotate the secret on a schedule you set, update the Okta app and the Secret together, and confirm the Argo CD pods pick up the new value.

Scope service account credentials

Okta's November 3, 2023 root cause analysis reported that an attacker reached files in its customer support system using a service account whose credentials an employee had saved to a personal Google profile. The lesson for this integration is to keep every credential in a controlled store, give each one the narrowest scope it needs, and rotate it. Apply the same rule to any Okta API token or automation account used to export users or groups.

Enforce TLS on the Argo CD endpoint

The Okta redirect URIs and the CLI callback both depend on the Argo CD external URL, so that URL must use HTTPS with a certificate your clients trust. Argo CD encrypts its own internal traffic, but ingress and load balancer configuration sit outside that scope and must be checked separately. Confirm that the Argo CD URL in the Okta app matches the url setting exactly, including the scheme and host.

Limit project-level permissions

Okta groups grant global Argo CD roles through policy.csv, but project roles define what each team can deploy and where. Bind groups to project roles that name only the repositories, destination clusters and namespaces that team owns. Argo CD redacts cluster, Git and OAuth2 credentials from API responses and logs, which reduces exposure, but it does not replace narrow project boundaries. Test each mapping with a non-admin account before rollout.

Testing group mappings before users depend on them

Test the Okta group mapping with a small pilot group before any production team signs in through it. Create a dedicated Okta group, add two or three test accounts, and map that group to a read-only role in policy.csv. Sign in as each test account in a browser and confirm the Argo CD user interface shows only the applications and projects the read-only role allows, with no sync, delete or settings actions available. Then confirm the same users can run argocd login --sso from a workstation, using the CLI client configured for localhost:8085, and that argocd app list returns the expected applications. A failed CLI login at this stage usually points to the separate CLI client or its redirect URIs rather than the group mapping itself.

Next, prove the negative. Sign in with an Okta account that belongs to no mapped group and confirm it either cannot sign in or sees no applications, projects or clusters. Repeat with a user who is in a group that has no Argo CD mapping at all. These checks catch the most common mistake in group-based RBAC, which is a default policy or a broad wildcard that grants more than intended. Keep policy.default empty unless you have decided otherwise, and review the result of each check against the role definitions in your own repository rather than against memory of what you configured.

Group changes take effect only when the user receives a new token, so test that explicitly. Add a pilot account to the mapped Okta group, log out of Argo CD in the browser and from the CLI, sign in again, and confirm the new permissions appear. Then remove the account from the group, repeat the logout and login, and confirm access is gone. Record which Okta group identifier or name appears in the token claim, because the scopes setting and group identifiers determine what Argo CD compares against. Document this test sequence in your change record so that the same checks run again after any Okta policy change or Argo CD upgrade.

Why Okta login to Argo CD fails and how to fix it

This table lists the failures teams most often hit when wiring Okta into Argo CD, with the likely cause and the check to run in Okta and in Argo CD. Work down the rows in order of the login flow: redirect, token, groups, CLI, roles, then the SAML fallback and access policy.

Symptom	Likely cause	Fix to verify in Okta and Argo CD
Redirect URI mismatch after clicking log in	The web app's sign-in redirect URI in Okta does not exactly match the Argo CD URL, including scheme, host and the /auth/callback path	In Okta, confirm the sign-in redirect URI is In Argo CD, confirm the url setting in argocd-cm matches the same host, then retry in a private browser window
Login succeeds but no groups appear in the token	The groups scope was not requested by Argo CD, or the custom authorization server does not return it	Check the scopes setting in argocd-cm includes groups. In Okta, confirm the groups scope and groups claim exist on the custom authorization server and are included in the access token
Groups scope is missing or rejected	Returning the groups scope requires Okta's API Access Management, which is a paid add-on outside developer edition	Confirm the add-on is licensed for your tenant before building the mapping. If it is not available, plan SAML through Dex as the fallback and confirm the attribute statement with Okta
argocd login --sso fails on localhost:8085	The CLI uses a separate single-page app in Okta, and its redirect URIs do not include localhost:8085	Create or check the CLI app in Okta with localhost:8085 redirect URIs and its own client ID. Confirm the CLI client ID configured in Argo CD matches that app, then rerun the login from a terminal
User signs in but has no Argo CD permissions	Group names or IDs in policy.csv do not match the groups claim value, or the default policy is empty	Compare the value in the token with the g lines in policy.csv, including case and whether the claim holds names or IDs. Test the mapping with the RBAC check in Argo CD before rollout
SAML fallback does not pass the expected group attribute	The SAML attribute statement in the Okta app omits the group attribute, or its name differs from the one Dex expects	In Okta, add a group attribute statement with a matching name and filter. In Argo CD's Dex configuration, confirm the groups attribute name matches exactly, then sign in and check the group values Dex receives
Access policy blocks the Argo CD app	The app is not assigned to an access policy on the custom authorization server, or the policy rule excludes the user's group	In Okta, confirm the access policy is assigned to the Argo CD web app and that a rule allows the users or groups who need access. Check the system log for the denied request
Admin access does not work after SSO is enabled	The built-in admin user was disabled before any SSO role mapping was tested	Keep one tested SSO admin mapping in policy.csv before setting admin.enabled to false. Confirm a second administrator can sign in before disabling the local admin account

What Okta SSO for Argo CD costs and requires

Does Okta SSO for Argo CD require a paid Okta license?

Signing in with Okta works on the standard OIDC flow, but returning a groups claim needs Okta's API Access Management add-on, which the Argo CD Okta guide says is free on the developer edition and a paid add-on in production. Okta's own packaging places API Access Management in the Enterprise suite, so confirm with Okta which edition and add-on your tenant holds before you design the groups setup. Without groups, Argo CD can still authenticate users, but role mapping by group is not available on that path. Ask your Okta account team to confirm the exact entitlements against your contract.

How is Okta priced for workforce identity?

Okta sells Workforce Identity suites priced per user per month, billed annually, with a $1,500 annual contract minimum according to the Okta pricing page. The suite tier you need depends on the features you use: the Starter suite includes Single Sign-On, Multi-Factor Authentication and Universal Directory, Essentials adds Adaptive MFA, Lifecycle Management and Access Governance, and Enterprise adds API Access Management, Access Gateway and machine-to-machine tokens. The groups scope for Argo CD points toward the higher tiers, so model the per-user cost against the tier that includes the add-on. Because pricing is per user, the head count that signs in to Argo CD is only part of the total; the rest of your workforce on the same tenant also counts. Get a written quote from Okta that lists the suite, user count and add-ons separately.

What drives the effort of an Okta and Argo CD setup?

The main drivers are the number of groups that must reach Argo CD, the fallback you choose if the groups claim is not available, and how many Argo CD projects and roles those groups map to. A small set of groups mapped to a few roles is a bounded task, while many groups, nested groups or per-project access rules add review and testing time. The fallback matters too: the Argo CD guide suggests SAML through Dex when the groups claim cannot be returned, which adds a second component to configure, secure and upgrade. The CLI client, which needs its own Okta application with localhost redirect URIs, and the number of environments (development, staging, production) also multiply the work. Ask any partner to split its quote by these items.

Can an internal team set up Okta SSO for Argo CD alone?

An internal team with Okta administration skills and Argo CD operations experience can usually complete the setup alone, provided it has the right Okta licenses and admin rights. The work spans Okta configuration (a custom authorization server, a groups scope and claim, an access policy for the web app and a separate single-page app for CLI login), Argo CD settings for the OIDC connection and RBAC policy, and testing of each login path. Teams that do not run Argo CD in production, or that lack anyone who has managed Okta authorization servers, often benefit from an outside partner for the design review and cutover. Whichever way you go, agree on who owns the Okta tenant changes and who owns the Argo CD RBAC file.

What access does an Okta and Argo CD project need from each team?

The project needs an Okta administrator who can create the custom authorization server, scopes, claims, access policies and applications, and who can confirm the entitlements on your tenant. It also needs a cluster administrator who can edit the Argo CD configuration, secrets and RBAC settings in the cluster where Argo CD runs, and who can restart or roll the Argo CD components after changes. If Dex is used as the fallback, the cluster team must also manage its configuration and TLS. A named owner on each side should approve the group names and role mappings before testing begins. Plan a test group of accounts in Okta so that production users are not exposed to trial changes.

How long does it take to validate Okta SSO for Argo CD?

No validated duration is available for this setup, so treat any timeline you are given as a proposal to check rather than a fact. Validation depends on how many login paths you test (web UI, CLI, and any fallback), how many groups and roles you map, and how quickly the Okta entitlements are confirmed. Testing should cover a user in each group, a user in no group, a user removed from a group, and a CLI login, before any production change. Ask a partner for a written schedule that lists each validation step, the owner of each step and the exit criteria for each one.

What should a quote for Okta SSO for Argo CD include?

A useful quote lists the scope in writing: the Okta objects to configure, the Argo CD settings and RBAC mappings, the number of groups in scope, whether a Dex fallback is included, and the environments covered. It should separate one-time work (design, configuration, testing and cutover) from recurring work such as upgrades, Okta changes and support. The quote should also say what the client provides, including Okta admin access, the entitlements to be confirmed, and cluster access. Ask how acceptance is tested and who signs off. DeployOpen works from a written scope and does not publish a price list, so a quote follows from the scope you agree.

What are the security risks of an Okta integration for Argo CD?

The main risks are over-broad group mappings that grant more Argo CD access than intended, long-lived client secrets, and an Okta tenant whose administrators are not tightly controlled. Argo CD's RBAC is only as narrow as the group names it trusts, so review every mapping and avoid default broad roles for large groups. Okta's own 2023 incident, in which a service account's saved credentials led to access to customer support files, is a reminder to keep service credentials in managed vaults and to review admin access regularly. Argo CD should also have its built-in admin user disabled once SSO works, as the user management documentation recommends.

What DeployOpen covers and what stays with your Okta team

Within a fixed written scope, DeployOpen plans and configures the Argo CD side of this integration: the OIDC client settings in the Argo CD configuration, the custom authorization server and groups claim that Argo CD reads, the mapping from Okta groups to Argo CD roles in the RBAC policy, the separate CLI client for argocd login --sso, and a test plan that proves each group lands in the intended role before anyone relies on it. The written scope also states which clusters, projects and Argo CD version the work covers, so the boundary is visible before the build starts.

Your Okta team keeps ownership of the tenant. That includes the Okta licensing decision, the add-on that returns the groups scope in production (the Argo CD Okta guide notes that this API Access Management capability is a paid add-on outside developer editions), the administrator accounts, the access policies that decide who may reach the Argo CD app, and the user lifecycle: joiners, movers, leavers and the group memberships that drive Argo CD permissions. Confirm with Okta which edition and add-ons your contract includes, since the features needed here are not all in the same suite. Confirm also who approves changes to group membership, because those changes now alter what people can deploy.

DeployOpen prepares configuration, records and test evidence that your own assessors can review, but it does not issue audit reports, attestations or certifications. Any compliance conclusion about your access controls comes from your internal audit or an independent auditor. Ask for the test results and the change record as deliverables in writing, and agree in advance who signs off the role mapping, so that the handover leaves your team able to change groups and roles without a new engagement.

How DeployOpen scopes and delivers Argo CD SSO with Okta

DeployOpen plans, implements, documents and supports Argo CD in infrastructure you control, including its sign-in integration with Okta. The work starts with a written scope that fixes which Okta authorization server, groups mapping and fallback path your organization will use before any configuration changes are made.

How we scope

Written scope names the Okta org, authorization server, and whether the groups claim is available on your Okta edition.
Scope records which Argo CD roles and project boundaries each Okta group will map to.
Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we build

Configure the custom authorization server, groups scope, claim and access policy for the Argo CD web app.
Set up the separate CLI client with localhost redirect URIs and test argocd login end to end.
Where groups cannot be returned, build SAML through the bundled Dex as the documented fallback and test it.

How we hand over

Deliver written configuration records, RBAC policy mapping and a test log for each sign-in path.
Document the steps to disable the built-in admin user once SSO is verified, and how to revert.
Walk your platform and security teams through troubleshooting, group changes and ongoing ownership of the mapping.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Support can cover Argo CD minor upgrades and re-validation of the Okta sign-in and group mappings after each change.
Ask for the support scope, response expectations and upgrade handling in the written quote before signing.

Argo CD SSO with Okta