Sign Into ArgoCD with GitHub OAuth (2026)

Signing into ArgoCD with GitHub OAuth is less about authentication and more about authorization to your Git provider.

Let’s see it in action. Imagine you’ve got ArgoCD running, and you’ve configured it to use GitHub for logins. Your users, instead of seeing a username/password prompt for ArgoCD itself, see a "Login with GitHub" button.

<button class="btn btn-primary" onclick="window.location.href='/oauth/login/github'">Login with GitHub</button>

When they click that, they’re redirected to GitHub. GitHub asks them, "Hey, do you authorize this app (ArgoCD) to see your basic profile info and email?" If they say yes, GitHub sends a token back to ArgoCD. ArgoCD then uses that token to ask GitHub, "Who is this person, really?" GitHub confirms their identity, and ArgoCD checks its own internal RBAC (Role-Based Access Control) rules to see what that identified user is allowed to do within ArgoCD.

The core problem ArgoCD’s GitHub OAuth solves is delegating identity verification. Instead of ArgoCD needing to securely store and manage user credentials (passwords, etc.) for potentially hundreds of developers, it outsources that to GitHub, a service already trusted by your team. This dramatically simplifies security and user management for ArgoCD itself.

Internally, it’s a standard OAuth 2.0 flow.

1. Initiation: User clicks "Login with GitHub" in ArgoCD.
2. Authorization Request: ArgoCD redirects the user to GitHub’s authorization server with specific client_id and redirect_uri parameters.
3. User Consent: GitHub prompts the user to authorize ArgoCD to access their GitHub profile.
4. Authorization Code Grant: Upon consent, GitHub redirects the user back to ArgoCD’s redirect_uri with an authorization_code.
5. Token Exchange: ArgoCD exchanges this authorization_code with GitHub’s token endpoint for an access_token and an id_token.
6. User Info Fetch: ArgoCD uses the access_token to call GitHub’s User API (e.g., https://api.github.com/user) to retrieve the user’s identity information (username, email, etc.).
7. ArgoCD RBAC: ArgoCD then matches this retrieved user identity against its own RBAC configuration to determine what actions the user can perform within the ArgoCD UI.

The exact levers you control are in ArgoCD’s argocd-cm ConfigMap, specifically under the oidc.config section. You’ll define:

• name: A descriptive name for the provider (e.g., github).
• issuer: The URL of the identity provider. For GitHub, this is typically https://github.com.
• clientID: Your application’s client ID obtained from GitHub OAuth Apps.
• clientSecret: Your application’s client secret.
• scopes: The OAuth scopes you request from GitHub. read:user and user:email are common.
• requestedClaims: (Optional) Specific claims you want to be returned.

Here’s a snippet of what that might look like in your argocd-cm ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cm
  namespace: argocd
data:
  oidc.config: |
    github: |
      name: GitHub
      issuer: https://github.com
      clientID: <your-github-client-id>
      clientSecret: <your-github-client-secret>
      scopes: 
      - read:user
      - user:email

The most surprising part of this setup is that ArgoCD doesn’t actually store any credentials for your users. It relies entirely on the tokens provided by GitHub. If a user revokes ArgoCD’s access on GitHub, they’ll immediately be unable to log into ArgoCD, even if their ArgoCD user entry still exists. This makes revocation a very immediate and clean process.

Once you have GitHub OAuth configured, the next natural step is to integrate that identity into ArgoCD’s Role-Based Access Control (RBAC) to grant granular permissions.