title:"Setting up OAuth2 for GitOps"

description:""

description:"Set up Git authentication with OAuth2"

group:administration

sub_group:account-user-management

toc:true

Codefresh integrates with the Git provider defined for yourGitOps runtime accountto sync repositories to your clusters, implementing Git-based operations when creating resources such as Delivery Pipelines, applications, and enriching images with valuable information.

Codefresh integrates with the Git provider defined for youraccount with the GitOps Runtimeto sync repositories to your clusters, implementing Git-based operations when creating resources such as applications, and enriching images with valuable information.

As the account administrator, you can select the authentication method fora runtimeaccount. Users in Codefresh will then authorize access to the Git providers through the defined mechanism.

As the account administrator, you can select the authentication method fortheaccount with Runtime. Users in Codefresh will then authorize access to the Git providers through the defined mechanism.

{% include

image.html

Codefresh supports OAuth2 or personal access tokens (PATs) for authentication:

* OAuth2 with Codefresh OAuth Application or custom OAuth2 Application

***OAuth2 with Codefresh OAuth Application or custom OAuth2 Application**

OAuth2 is the preferred authentication mechanism, supported for popular Git providers such as GitHub, GitHub Enterprise, GitLab Cloud and Server, and Bitbucket Cloud and Server.

You have the option to use the default predefined Codefresh OAuth Application, or a custom Oauth2 Application for Codefresh in your Git provider account.

Hosted runtime accounts automatically use Codefresh's predefined OAuth Application.

To use a custom Oauth2 Application for Codefresh, first create the application in your Git provider account, then create a secret on your K8s cluster, and finally configure OAuth2 access for the custom application in Authentication > Settings. See[Create a custom OAuth2 Application for Git provider](#create-a-custom-oauth2-application-for-git-provider) in this article.

To use a custom Oauth2 Application for Codefresh, first create the application in your Git provider account, then create a secret on your K8s cluster, and finally configure OAuth2 access for the custom application in Authentication > Settings. <br>

See[Create a custom OAuth2 Application for Git provider](#create-a-custom-oauth2-application-for-git-provider) in this article.

* Token-based authentication using PAT

With token-based authentication, users must generate personal access tokens from their Git providers with the required scopes and enter their personal access tokens when prompted to authorize access. See[Authorize Git access in Codefresh]({{site.baseurl}}/docs/administration/user-self-management/user-settings/#git-provider-private-access).

***Token-based authentication using PAT**

With token-based authentication, users must generate personal access tokens from their Git providers with the required scopes and enter their personal access tokens when prompted to authorize access.<br>

See[Authorize Git access in Codefresh]({{site.baseurl}}/docs/administration/user-self-management/user-settings/#git-provider-private-access).

The[Git Authentication](https://g.codefresh.io/2.0/account-settings/authentication?providerName=github){:target="\_blank"} page displays the accounts by Git provider and the authentication method selected for the same.

Authentication accounts are organized by Runtimes. Aruntime can have a single authentication account.

Authentication accounts are organized by Runtimes. ARuntime can have a single authentication account.

The Type column identifies the authentication for the provider account as either Codefresh, Custom, or PAT (personal access token).

{% include

max-width="80%"

%}

As the account administrator, you can change the authentication method for a Hybrid GitOps runtime at any time to either Codefresh, Custom, or manual token entry. See[Select authentication mechanism for runtime](#select-authentication-mechanism-for-runtime).

As the account administrator, you can change the authentication method for a GitOps runtime at any time to either Codefresh, Custom, or manual token entry. See[Select authentication mechanism for runtime](#select-authentication-mechanism-for-runtime).

Create a custom OAuth2 Application for Codefresh in your Git provider accounts with the correct scopes, and set up authentication for the same within Codefresh. Users in Codefresh can then authorize access to the Git provider using OAuth2, instead of a personal access token.

* For**Authorization callback URL**, enter this value:

where:

`<ingressHost>` is the IP address or URL of the ingress host in the runtime cluster.

`<ingressHost>` is the IP address or URL of the ingress host in the Runtime cluster as defined in your`values.yaml`. <br>For

tunnel-based access modes, run the command`codefresh runtime list` to retrieve the correct host.

* Make sure**Enable Device Flow** is_not_ selected.

* Select**Register application**.

The client ID is automatically generated, and you are prompted to generate the client secret.

For a Git provider and aruntime account, select the authentication mechanism:Codefresh account, Custom provider account if one exists, or token-based authentication.

For a Git provider and aRuntime account, select the authentication mechanism:Codefresh account, Custom provider account if one exists, or token-based authentication.

title:"Git tokens for GitOps"

description:"Understand Git tokens and scopes required forGitOps"

description:"Understand Git tokens and scopes required forGit authentication"

group:security

redirect_from:

-/docs/administration/git-tokens/

Codefresh requires two types of Git tokens for authentication in GitOps, a Git Runtime token, and a Git user token. The Runtime and user tokens are both Git access tokens which Codefresh uses for different purposes. See[Git Runtime tokens versus Git user tokens in Codefresh](#git-runtime-tokens-versus-git-user-tokens-in-codefresh).

Codefresh requires two types of Git tokens for authentication in GitOps, a Git Runtime token, and a Git user token. The Runtime and user tokens are both Git access tokens used for different purposes. See[Git Runtime tokens versus Git user tokens in Codefresh](#git-runtime-tokens-versus-git-user-tokens-in-codefresh) and[Interaction between Argo CD secrets and Git tokens](#interaction-between-argo-cd-secrets-and-git-tokens).

* The[Git Runtime token](#git-runtime-token-scopes) is mandatory for every GitOps Runtime. It must be provided during the Runtime installation, and is typically associated with a service/robot account.

* The[Git user token](#git-user-access-token-scopes) is an access token that is unique to every user in the Codefresh platform. It is required after installation for every Runtime which the user has access to.

| Managed by| Admin at account-level| User|

| Associated Account Type| (Recommended)[Service account or robot account](#use-a-servicerobot-account-for-gitops-runtimes)| User account|

Codefresh needs access to Git repositories for reading and writing to configuration and resource manifests. This section elaborates on how Git providers and repositories with Git tokens for authentication to .

The Git Runtime token is the personal access token provided during Runtime installation and is automatically converted to a secret. The secret for the Runtime repository is stored in the`runtime-repo-creds-secret` secret, labeled with`argocd.argoproj.io/secret-type: repo-creds`.

This label

The Runtime uses the same credentials

The secret:

* Allows Argo CD to use the credentials to clone and pull data from the repositories it syncs from for read-only operations.

* Allows the Runtime to both read and write to the same repositories, for all actions on behalf of the Runtime such as commits during promotions.

The Git user token, also a personal access token, is used for operations initiated by the user via the UI, and is therefore unique to each user.

The Git user token is also converted to an encrypted secret, and stored in the`git-default-<account-id>` secret.

The token is used to:

* Perform Git commits and pushes on behalf of the user.

* Validate the user’s access permissions to specific Git repositories and determine application visibility.

The table below lists the scopes required for Git Runtime tokens for the different Git providers. You can also create a Git Runtime token with custom scopes and[add it directly to the`values.yaml` file](#git-runtime-token-in-valuesyaml).

You also have the option to directly add your Git Runtime token, or a reference toa secret that contains theGitRuntimetoken, to`values.yaml` (typically the latter).

You also have the option to directly add your Git Runtime token, or a reference tothe secret that contains the Runtimesecret, to`values.yaml` (typically the latter).

To skip token validation both during installation and upgrade in this scenario, add the`skipValidation` flag to`values.yaml`.