Argo CD CLI single sign-on and PKCE

A redirect URI mismatch means the callback address the CLI or Argo CD sends to your identity provider is not registered exactly as sent on the client application. Compare the redirect URI in the failing browser step with the list on the client in your provider, character by character, including scheme, host, port and trailing slash. Check the CLI client separately from the web client, since each needs its own registration. Argo CD's CLI uses a localhost callback, so the port in the provider must match the port the CLI listens on. Your provider's sign-in log usually names the redirect URI it received, which is the fastest way to see the difference. Confirm the exact expected values against the user management guide and your provider's documentation before editing the client.

The most likely cause is that the /auth/callback endpoint is missing from the client's redirect URIs. From Argo CD 3.1, the server handles the OIDC authorization code flow itself, and with PKCE enabled the callback must be registered on the identity provider client. Check the redirect URI list on both the web and CLI clients after the upgrade, and add the /auth/callback path on your Argo CD hostname where it is absent. Review the 3.0 to 3.1 upgrade notes before the change so you know which flow your installation uses. Test with a non-administrator account after the change, because a failure that appears only for new sign-ins usually points back to the registered redirect URIs.

The login flow fails because the provider cannot validate the code challenge that Argo CD sends, so the sign-in does not complete. PKCE is turned on with enablePKCEAuthentication in oidc.config, it defaults to false, and it depends on identity provider support. Before enabling it, confirm in your provider's documentation that the client type and configuration accept PKCE with the authorization code flow. If you are unsure, set the key back to false, restore the previous working login, and then test PKCE in a non-production Argo CD instance. Record the setting and the provider version in your change record so the next upgrade does not change the behavior unexpectedly.

The logout redirect is controlled by the logoutURL setting in oidc.config, so an unexpected page usually means that value is wrong or missing its placeholders. The setting accepts {{token}} and {{logoutRedirectURL}} placeholders, which Argo CD fills in at logout. Compare your configured URL with your provider's documented end-session or logout endpoint, and check that the post-logout redirect address is also registered on the provider client. Test a logout in a private browser window, then a logout from the CLI session, since they can take different paths. Confirm the endpoint format with your provider, because a logout URL that is accepted in one tenant can be rejected in another.

A localhost port conflict happens when another process already listens on the port the CLI needs for its callback, so the browser redirect cannot reach the CLI. Engineers can check which process holds the port with the operating system's network tools, then stop it or retry after closing the conflicting application. The more durable fix is to align the callback port with what your identity provider allows for the CLI client, since a port that is not registered will fail on the provider side even when it is free. Ask your identity team whether the CLI client accepts localhost with a varying port, because provider behavior differs. Document the agreed port in the onboarding guide so every engineer's laptop behaves the same way.

The work sits across two teams: the platform team that controls Argo CD configuration and the identity team that controls the client registrations on your provider. The platform team owns oidc.config, the server hostname and the logout settings, while the identity team owns redirect URIs, client types and the PKCE capability of the provider. Agree on a single change record that lists both sides, so an edit to one does not silently break the other. If your organization does not have clear ownership of the CLI client, assign it before the next Argo CD upgrade. DeployOpen can plan and document this integration as part of a fixed-scope engagement, with the written scope defining which of these items are included.

Many teams can fix these errors in-house because the checks are specific and visible in the configuration and the provider console. The work is mainly reading redirect URIs, testing sign-in paths, and making small changes to oidc.config and client settings. The effort rises when several identity providers, a custom authorization server or a regulated change process are involved, because each change needs testing and evidence. Your internal team should have access to both the Argo CD admin configuration and the identity provider administration, and a non-production instance to test changes first. If those access paths or test environments are not available, a scoped engagement can cover the diagnosis and the fix together.

The effort is mostly configuration and testing, not new software, because the CLI reuses the identity provider you already run for the web UI. The work covers creating a client for the CLI, setting PKCE and redirect URIs, testing login from a workstation and a CI-adjacent host, and confirming logout behaves. Effort rises when the identity provider needs custom claims, when several providers are involved, or when the Argo CD version requires the server-side callback. Ask any partner to break the estimate into identity provider changes, Argo CD configuration changes and test rounds, so you can see which part your own team can absorb.

Testing duration depends on how many user groups, browsers, operating systems and networks you need to cover, and on how quickly your identity team can change client settings. A reasonable plan tests a few named users on each supported workstation, then a wider pilot group, before the change reaches everyone. Confirm with your identity team how long their change process takes for client edits, because that step often sets the pace more than the Argo CD side does.

The identity team owns the client that the CLI uses, so they need to provide the work below before the Argo CD side can be tested:

• A dedicated CLI client, with its client ID and the localhost callback allowed
• PKCE support enabled on that client, if your provider requires it for public clients
• Redirect URIs that include the Argo CD server callback path when PKCE is used on Argo CD 3.1 or later
• A logout redirect target that the provider accepts

Ask them to confirm these settings in writing, because the exact menu names differ by provider.

The platform team edits the Argo CD configuration and runs the tests on the cluster. That means setting enablePKCEAuthentication and the logout URL in oidc.config, confirming the Argo CD version and its callback behavior, checking that the web UI still signs in, and recording the working login command for engineers. They also need access to the Argo CD server logs during testing, because redirect errors are easiest to diagnose there. Plan for the change to be reviewed through your normal change process.

Yes, a team with someone who administers the identity provider and someone who manages the Argo CD configuration can usually complete this themselves, since the steps are documented in the official user management guide. A partner adds value when the team lacks an identity administrator, when the provider is unusual, or when the work must be done within a fixed timeline with written test evidence. Decide based on who has the access and the time, and confirm that your identity administrators can make the client changes without a long approval cycle.

The main cost drivers are the number of identity providers, the number of Argo CD instances that share one identity configuration, the presence of custom claims or group mappings that need separate testing, and the number of approval steps your change process requires. Redirect errors that come from proxies, certificates or network paths also add time, because they require coordination with the network team. Work that is already documented and uses a single provider usually costs less to validate than a mixed environment.

Ask for a written scope that lists the Argo CD version and instances covered, the identity provider and client settings to be configured, the PKCE and callback settings, the logout behavior to be verified, the test cases and who runs them, and the handover documents. Also ask which tasks the identity team performs, which the platform team performs, and which are the partner's responsibility. Confirm what is one-time work and what recurs, such as checks after each Argo CD upgrade, and whether ongoing support is handled through a separate retainer.