Argo CD SSO with Auth0: OIDC setup and RBAC

How Argo CD SSO with Auth0 works and when to choose it

If your platform team runs Argo CD in clusters you control and Auth0 is already where your people sign in, the supported path is direct OIDC against an Auth0 application. Argo CD trusts Auth0 as its identity provider, and group or role membership reaches Argo CD in a token claim that an Auth0 Action adds to the login token. Argo CD then maps that claim to its RBAC policy. Dex is not needed for this path. The main decision is whether Auth0 will be the source of group membership for Argo CD at all, or whether you will keep Argo CD roles in a separate system and only use Auth0 for identity.

The Argo CD user management guide links a provider guide for Auth0, and it lists Auth0 among several direct OIDC options alongside Okta, Microsoft, Keycloak and Google. Choosing Auth0 usually follows from a decision the organization has already made about its workforce identity. Confirm that before you start, because Argo CD itself does not change how Auth0 authenticates users. Also confirm which Auth0 plan and tenant region fit your data residency needs, since tenant regions are fixed at creation and the tenant name cannot be changed later.

Plan the claim design before the Argo CD configuration. Auth0 does not emit a groups or roles claim by default, so you will write an Action that copies the membership data into a namespaced claim, and the Argo CD scopes setting and policy.csv must match that claim name exactly. Decide which Auth0 identifiers become Argo CD groups, how many groups each user can carry, and who may change those assignments. Treat Auth0 as a second place where access is granted, so changes to Auth0 roles or Organizations affect Argo CD access, and test that path with a non-admin account before rollout. Keep the local admin account as a break-glass path until SSO is verified.

What you need before configuring Auth0 and Argo CD

Five things need to be settled before you touch either system: a reachable Argo CD instance with TLS, a deliberate Auth0 tenant, a plan that covers the features you will use, a supported Argo CD version, and admin access on both sides. Getting these right first avoids most redirect and permission problems later.

Argo CD instance and external URL

Argo CD needs a stable external URL with TLS that users and the browser can reach. This URL becomes the base for the Auth0 callback and logout settings, so changing it later means updating Auth0 and the Argo CD url setting together. Confirm the hostname, certificate chain and ingress path before you start, and decide whether the CLI will also sign in through this address.

Auth0 tenant and region

Auth0 public cloud tenants can be created in Australia, Canada, Europe, Japan, the United Kingdom or the United States. Choose the region with your data residency rules in mind, because a tenant name cannot be changed after creation. Pick a name that identifies the environment, such as production or staging, so it is not reused by mistake.

Plan level for the features you use

Confirm that the Auth0 plan covers what you plan to use, such as enterprise connections, Organizations, or the custom database connection if your users live there. Compare your expected monthly active user count against the plan limits on the pricing page. Ask your Auth0 account contact to confirm plan fit in writing before rollout, since a plan change later can affect your configuration.

Argo CD version support

Check the Argo CD version you run against the current minor releases. The project patches only the three most recent minor versions, so an older release may stop receiving fixes before you finish the SSO work. Confirm the version in your cluster and plan any upgrade first, because the 2.14 to 3.0 changes to RBAC and repository handling affect how group mappings behave.

Admin access on both sides

You need cluster-level access to edit the argocd-cm and argocd-rbac-cm ConfigMaps and to restart Argo CD components, plus an Auth0 Dashboard account with rights to create applications, actions and test users. Keep the built-in admin account available until SSO works, then plan to disable it with admin.enabled set to false. Record who holds these roles before the change window opens.

Configure Auth0 and Argo CD in sequence

This sequence connects Argo CD to an Auth0 application so that users sign in through Auth0 and their group or role membership arrives as a claim that Argo CD can map to RBAC. Each step ends with a check so the team can confirm the claim and mapping before anyone relies on them.

Create the Auth0 application for Argo CD
In the Auth0 Dashboard, create a regular web application for Argo CD in the tenant your organization has chosen for workforce sign-in. Set the allowed callback URL to the Argo CD address with the /auth/callback path, and set the allowed logout URL to the Argo CD base address, using the exact hostname and TLS scheme your installation serves. Record the domain, client ID and client secret, and confirm the application's token endpoint authentication method matches the one you configure in Argo CD. Check: the application shows the callback and logout URLs you entered, and a test sign-in from a browser reaches the Auth0 login page without a redirect error. Confirm the exact paths against the Argo CD user management guide for your Argo CD version before you finalize them.
Add an Auth0 action that writes the groups claim
Auth0 does not include group or role membership in the ID token by default, so create a Login flow Action that reads the user's roles or organization membership and adds them as a custom claim. Use a namespaced claim name, such as a URL you control, so the name cannot collide with reserved claims, and agree that name with the platform team before you write it into Argo CD. Deploy the Action and add it to the Login flow. Check: sign in as a test user, then decode the ID token (for example with a JWT inspection tool in a non-production setting) and confirm the claim appears with the expected values. Ask your Auth0 administrator to confirm which plan and features your tenant can use for this approach, since plan limits are listed on the Auth0 pricing page.
Store the client secret in a Kubernetes Secret
Create a Kubernetes Secret in the namespace where Argo CD runs that holds the Auth0 client secret. Argo CD reads the value through a secret reference in its configuration, so the secret never appears in the argocd-cm ConfigMap or in Git. Restrict who can read the Secret using Kubernetes RBAC, and record where the value is sourced from so rotation has a clear owner. Check: the Secret exists with the expected key name, and a query that lists the ConfigMap returns no plain-text client secret. If your organization uses an external secret store, confirm with your security team whether the Secret should be synchronized from it rather than created by hand.
Set the OIDC configuration in argocd-cm
Edit the argocd-cm ConfigMap to set the Argo CD URL and the OIDC block. Point the issuer at your Auth0 tenant domain, set the client ID, reference the client secret key from the Kubernetes Secret, and set the requested scopes so the custom claim is included. Keep the configuration in the same Git repository that manages the rest of your Argo CD installation so changes are reviewed. Restart the Argo CD server components if your deployment method requires it. Check: the Argo CD login page offers an Auth0 or OIDC sign-in option, and completing it returns you to Argo CD without an error about the issuer, audience or redirect. Confirm the exact key names against the user management documentation for your version.
Map the claim values in argocd-rbac-cm
Set the scopes and the claim name in argocd-rbac-cm so Argo CD reads the groups or roles claim, then add policy lines that bind each claim value to an Argo CD role. Start with a read-only role for a test group, and bind administrative permissions only to a group your team has approved. Keep the default policy restrictive so users without a mapped value receive no access. Check: sign in with a test user from each group and confirm the expected permissions, for example by attempting an action the role should deny. Record each mapping in your change system so auditors can trace who received which access and when.
Confirm group membership in the user info view
After the mapping is in place, sign in as a test user and open the user information view in the Argo CD interface, or query the user info endpoint with a token from that session. Confirm that the groups or roles values from Auth0 appear as expected and that the effective permissions match the policy you wrote. Repeat the check for a user who should have no mapped group, and confirm access is denied. Check: every test user shows the expected groups and permissions, and no unmapped user gains access. Keep the test accounts documented so the same checks can be repeated after upgrades or policy changes.
Verify logout and disable the local admin
Test the logout path by signing out of Argo CD and confirming that the session ends and the Auth0 logout URL you registered is used without an error. Once SSO sign-in and RBAC are verified for at least one administrator group, follow the Argo CD user management guidance to disable the built-in admin user by setting admin.enabled to false, and keep a documented break-glass procedure for recovery. Check: a signed-out session cannot reach protected pages, and the admin login is disabled while an SSO administrator can still sign in. Record the break-glass owner and the location of its credentials in your operations runbook.

Choosing Auth0 features that affect the integration

Auth0 public cloud tenants can be created in Australia, Canada, Europe, Japan, the United Kingdom or the United States. The region is where your tenant runs, so it should match where your data residency and change control requirements place identity data. The tenant name cannot be changed after creation, so choose it deliberately, since it appears in the issuer URL that Argo CD will trust. If the public multi-tenant cloud does not fit your isolation or capacity requirements, Auth0 Private Cloud is a dedicated managed deployment on AWS or Azure. It is a different commercial and operational arrangement, so treat it as a separate decision rather than a setting change.

Region selection: Pick the public cloud region that matches your residency commitments before anyone creates an application.
Tenant naming: The name is fixed and forms part of the issuer URL in Argo CD's OIDC settings.
Dedicated isolation: Auth0 Private Cloud suits organizations that cannot use the multi-tenant public cloud or need guaranteed capacity.
Separate tenants: Decide whether production and non-production Argo CD environments share a tenant or use separate ones.
Network path: Confirm that your Argo CD server can reach the Auth0 domain and that your browsers and CLI users can too.

Confirm current region availability and Private Cloud terms directly with Auth0 before you commit.

Mapping Auth0 claims and users to Argo CD roles

This table maps each identity claim Argo CD reads from Auth0 to the setting or policy line that consumes it, and shows what each one grants. Read it top to bottom as a chain: the Auth0 Action emits a claim, Argo CD's scopes setting asks for it, and policy.csv matches its exact value to a role.

Element	What Argo CD does with it	What to check before rollout
email claim	Identifies the user in the Argo CD session and in audit logs; the email scope must be requested	Confirm every user has a verified email in Auth0, since accounts without one may be hard to trace
name claim	Shown as the display name in the Argo CD user interface	Cosmetic only; do not use it for access decisions
Groups or roles claim from the Action	Carries the Auth0 role or group names that policy.csv group lines match against	Add it in a post-login Action under a namespaced claim URL, because non-namespaced custom claims are not reliably emitted
scopes setting in argocd-cm	Tells Argo CD which claims to request from Auth0, for example openid, profile, email and the custom groups scope	If the custom claim is missing from the token, check that the scope name in this setting matches the claim you added
Claim namespace for custom claims	Argo CD reads the claim by its full name, so the namespace must match exactly in the Action and in the configuration	Use a URL you control as the namespace, and keep the spelling identical in every place it appears
Exact-match group values in policy.csv	A line such as g followed by the claim value and a role name grants that role only when the value matches character for character	Test with one account before rollout; case differences and trailing spaces cause silent denials
Project role bindings	Policy lines of the form p with a role, a project, an action and an object grant access inside one Argo CD project	Start with read-only roles and add sync or override rights only for named teams
Users without a matching group	Sign in succeeds but the user receives no effective permissions, or only the default policy	Confirm the default policy in argocd-rbac-cm is as restrictive as your change control requires

Security controls for an Auth0 login to Argo CD

An Auth0 login gives Argo CD a sign-in path, but the security of that path depends on how the Auth0 application, the Action and the Argo CD policy are configured together. The cards below cover the controls that connect them, from credential storage to the claims the Action is allowed to emit.

Client secret storage

The OIDC client secret for the Argo CD application should live in a Kubernetes Secret or an external secrets operator, never in a values file committed to Git. Limit who can read that Secret on the cluster, and plan a rotation step in Auth0 that updates the Secret and restarts Argo CD. Confirm with your platform team where rotation is recorded, since the rotation procedure is part of your change record. Treat the client secret as a credential with the same handling as a deploy key.

Restricting who can obtain tokens

Authentication alone does not decide who reaches Argo CD. Check the Auth0 application's access settings, and where your plan supports it, use Organizations or connection-level controls so that only the intended user populations can sign in to this application. Review which connections are enabled for the Argo CD application, since a social or database connection you did not intend to offer can widen the sign-in population.

Admin user for setup only

The built-in admin user is a local account that bypasses SSO. Use it to complete initial setup, then disable it by setting admin.enabled to false once SSO and RBAC work. Keep a documented break-glass path for the case where the identity provider is unavailable, and confirm who can use it and how that use is logged before you turn it off.

TLS on the Argo CD endpoint

Serve the Argo CD UI, API and CLI over TLS at the ingress or load balancer, and make sure the OIDC redirect and logout URLs use the same HTTPS hostname registered in Auth0. Argo CD encrypts traffic between its own components, but the external hop is your responsibility. Confirm certificate issuance, renewal and which CA your CLI users trust before go-live.

Least-privilege default policy

Set the default RBAC policy to a role with no permissions, so a user who signs in without a mapped group sees nothing useful. Grant access only through explicit group mappings in policy.csv, and scope application permissions to the projects each team owns. Test the mapping with a user from each group before rollout so that an unmapped user is denied as expected.

Minimal claims from Auth0 Actions

An Auth0 Action that adds a groups or roles claim runs code on every token issuance, so it can read more user data than RBAC needs and emit that data into tokens that Argo CD logs or caches. Limit the Action to reading the one attribute used for mapping, emit only the groups or roles claim, and avoid copying profile fields or metadata into the token. Review the Action code as part of the change record, because changes to it alter who gets which Argo CD access.

Token and credential handling

Argo CD authenticates API requests only with JSON Web Tokens, and it redacts OAuth2 credentials from API responses and logs. Those controls do not cover what your own tooling writes, so check that CI jobs, scripts and shell history do not capture tokens or the client secret. Confirm how long issued sessions last in your configuration and how a removed user's access ends.

Common Auth0 login failures and their fixes

This table pairs each common Auth0 sign-in failure with its usual cause and the fix to try first. Read it in order when a login breaks, because several symptoms share the same root cause, such as a missing Action or a mismatched callback URL.

Failure	Likely cause	Fix
Redirect URI mismatch on sign-in	The callback URL registered in the Auth0 application does not exactly match the Argo CD URL, including scheme, host, port and path.	Set the Argo CD external URL, then add the matching callback URL to Allowed Callback URLs in the Auth0 application and save.
Logout returns to an error page	The logout URL for the Argo CD host is missing from Allowed Logout URLs in the Auth0 application.	Add the Argo CD base URL to Allowed Logout URLs and test sign-out from a fresh browser session.
Groups claim missing from the token	The Auth0 Action that adds groups or roles was written but not deployed, or it is not bound to the Login flow.	Deploy the Action, add it to the Login flow in Actions, then sign out and sign in again so a new token carries the claim.
Claim namespace mismatch	The Action writes the claim under a different name or namespace than the one set in Argo CD's OIDC scopes and RBAC configuration.	Pick one claim name, use the same string in the Action and the Argo CD configuration, and inspect a decoded ID token to confirm the key.
Users land with default access	No policy.csv line maps the user's group to a role, so Argo CD applies the default policy.	Map each group to a role in RBAC, keep the default policy minimal, and test each mapping with a user from that group before rollout.
Logins fail after client secret rotation	The new secret was generated in Auth0 but the Kubernetes Secret or Helm value holding it was not updated, or Argo CD pods were not restarted.	Update the secret store, roll the Argo CD server pods so they reload it, and confirm the old secret is no longer referenced.
CLI login with argocd login --sso fails	The CLI needs its own Auth0 application and localhost callback, separate from the web application, and the callback is not registered.	Create or confirm the CLI client in Auth0, register its localhost callback, and review the CLI single sign-on setup for your Argo CD version.

Questions teams ask before connecting Argo CD to Auth0

What drives the cost of connecting Argo CD to Auth0?

The cost comes from the hours of configuration and testing, not from the Argo CD software, which is Apache-2.0 licensed with no paid edition from the project. The main components are tenant and application setup in Auth0, authoring the Action that adds a groups or roles claim, designing the RBAC policy in Argo CD, and testing sign-in and logout across roles. Auth0 itself is billed separately: the Free plan supports up to 25,000 monthly active users, and features such as custom database connections start on Professional. Ask any quote to list who pays for each component, which items are one-time, which recur (such as upgrades and access reviews), and which Auth0 plan the design assumes.

How long does an Argo CD and Auth0 SSO setup take?

Duration depends mainly on how many groups exist, where they live, and how much Auth0 is already in use. A team with a clean tenant, a small set of groups and one Argo CD instance has a much shorter path than one that needs Organizations, enterprise connections, or group membership pulled from another directory. Existing Auth0 usage also matters because changes to applications, Actions and login flows can affect other products on the same tenant. Ask for a timeline that is tied to a written scope, with the group design and test cases listed as separate milestones.

What does the client team need to provide for this work?

Three things are needed before work starts. First, Auth0 administrator access to the target tenant, or a named admin who can create applications, Actions and roles. Second, the authoritative group source, whether that is Auth0 roles, Organizations, an enterprise connection, or a directory behind it, along with a list of the groups that should map to Argo CD roles. Third, access to the Kubernetes clusters that run Argo CD, so the configuration can be applied and tested. Confirm who approves changes to the production tenant and where Argo CD configuration is stored before scoping begins.

Can our own team connect Argo CD to Auth0 without a partner?

Yes, an experienced platform team can do this in-house, since the work uses standard OIDC settings, an Auth0 Action and Argo CD RBAC configuration. The effort tends to concentrate in two places: designing a group model that stays manageable as teams change, and testing that the right people get the right roles and that no one gains access through a stale mapping. Teams without recent Auth0 or Argo CD administration experience often find the testing and rollback planning is the part they want help with. Compare the internal skills and capacity against the written scope before deciding.

Do we need to bulk export existing Auth0 users for Argo CD?

Usually not. Argo CD does not store its own user database for SSO users, so connecting it to Auth0 relies on Auth0 authenticating people at sign-in. A bulk export becomes relevant when you are migrating users to a different identity provider or auditing accounts. Auth0 supports bulk exports through the Dashboard or the Management API create export users job, in NDJSON or CSV format. Standard exports do not include password hashes. Customers on paid plans can request password hash exports through a support ticket, but Auth0 does not guarantee a delivery date and the option is not available on the Free tier, so plan that request early if a migration needs it.

Are password hashes included when we export users from Auth0?

No. Auth0 does not include password hashes in standard user exports. Customers on paid plans can request password hash exports through a support ticket. Auth0 does not guarantee a delivery date for that request, and the option is not available on the Free tier. If a migration depends on keeping existing passwords, raise this with Auth0 before the project timeline is set, and ask your security team how the exported hashes will be stored and deleted after use.

What breaks most often in an Argo CD and Auth0 integration?

The most common failures are redirect URI mismatches, a groups claim that is missing from the ID token or access token, and RBAC mappings that use group names where the token carries IDs, or the reverse. Logout problems also appear when post-logout URLs are not registered in Auth0. Test sign-in with a user in each role, check the claim contents in a decoded token, and confirm that removing a user from a group removes their Argo CD access. Keep the local admin account enabled only until SSO is verified, then disable it as the user management documentation recommends.

What moving existing Auth0 users into the setup involves

Argo CD does not store user passwords when SSO is configured, so moving Auth0 users into the setup is mostly an identity cleanup exercise rather than a credential migration. Users sign in at Auth0 and Argo CD trusts the resulting token, so the people who need access are defined by their Auth0 accounts, their group or role assignments and the Argo CD RBAC mappings that consume them. Before any export, decide which users should keep access, which are dormant or duplicated, and whether anyone is still signing in through a local Argo CD account. The users who matter are the ones who will hold a role in Argo CD, not the full tenant population.

Auth0 provides two export routes: the Dashboard, and the Management API create export users job (POST /jobs/users-exports). Both produce NDJSON or CSV files. NDJSON suits scripted filtering and transformation, while CSV is easier for a reviewer to scan when confirming which accounts to keep. Standard exports do not include password hashes. Only customers on paid plans can request password hash exports, and they do so through an Auth0 support ticket, with no guaranteed delivery date and no option on the Free tier. Confirm the export format, plan eligibility and any support timeline with Auth0 before you plan a cutover that depends on hashes, and check the current steps in the Auth0 bulk user exports documentation.

If your Auth0 tenant includes a database connection with its own users, treat that population as a migration in its own right. Export it, confirm the attributes you need survive the move, and decide whether users will re-register, reset passwords or import hashes. Argo CD is unaffected by which path you take, but the target identity provider is, so review that choice together with your Auth0 tenant and plan details and record who signs off on the exported data, since it contains personal information.

How DeployOpen scopes and delivers Argo CD SSO with Auth0

DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, and Argo CD SSO with Auth0 follows the same method. The work starts with a written scope that fixes the Auth0 tenant, the Argo CD instance, the claim design and the acceptance tests before any configuration changes are made.

How we scope

Confirm the Auth0 tenant region, plan and whether the Argo CD callback and logout URLs match your deployment hostname.
Agree whether Argo CD connects directly over OIDC or through the bundled Dex, and which claim will carry group membership.
Record which Argo CD roles, projects and CI accounts map to Auth0 groups or roles in the written scope.

How we build

Configure the Auth0 application, the post-login Action that adds the groups or roles claim, and the Argo CD OIDC settings in a version-controlled change.
Write policy.csv group mappings and test each role with real accounts in a non-production Argo CD before rollout.
Keep the local admin user available for recovery until SSO sign-in and RBAC tests pass, then disable it with admin.enabled set to false.

How we hand over

Deliver a configuration record covering tenant settings, Action code, callback and logout URLs, and the group-to-role mapping table.
Document the test cases, expected role outcomes and the steps to add or remove a group without disrupting other users.
Walk your identity and platform teams through the runbook for rotating the client secret and reviewing who can edit the Action.

How we support

Ongoing support, Argo CD upgrades and continuous testing are available as retainers after handover, scoped in writing.
Re-test SSO and RBAC after each Argo CD minor upgrade, since the upgrade notes change how RBAC and logs access behave.
Confirm with Auth0 the current plan limits, export and password hash options and tenant changes that affect your Argo CD setup before you commit.

Argo CD SSO with Auth0