Chapter 13. Configure OAuth for Git providers


Configure OAuth to allow OpenShift Dev Spaces users to interact with remote Git repositories without re-entering credentials.

OpenShift Dev Spaces supports GitHub, GitLab, Bitbucket Server (OAuth 2.0 and OAuth 1.0), Bitbucket Cloud, and Microsoft Azure DevOps Services. For each provider, you create an OAuth application, then apply the corresponding secret to your OpenShift Dev Spaces instance.

Note

Microsoft Entra ID replaces the deprecated Azure DevOps OAuth 2.0 application, which no longer accepts new registrations. If you have an existing Azure DevOps OAuth app, migrate to Microsoft Entra ID.

13.1. Set up the GitHub OAuth App

To enable users to work with a remote Git repository that is hosted on GitHub, register the GitHub OAuth App (OAuth 2.0).

Prerequisites

  • You are logged in to GitHub.

Procedure

  1. Go to the GitHub OAuth application registration page.
  2. Enter the following values:

    1. Application name: <application name>
    2. Homepage URL: https://<openshift_dev_spaces_fqdn>/
    3. Authorization callback URL: https://<openshift_dev_spaces_fqdn>/api/oauth/callback
  3. Click Register application.
  4. Click Generate new client secret.
  5. Copy and save the GitHub OAuth Client ID for use when applying the GitHub OAuth App Secret.
  6. Copy and save the GitHub OAuth Client Secret for use when applying the GitHub OAuth App Secret.

13.2. Set up a GitHub App

Set up a GitHub App as an alternative to a GitHub OAuth App to enable OpenShift Dev Spaces users to work with GitHub repositories.

Prerequisites

  • You are logged in to GitHub.

Procedure

  1. Register a GitHub App. See Registering a GitHub App.
  2. Enter the following values:

    1. GitHub App name: <application_name>
    2. Homepage URL: https://<openshift_dev_spaces_fqdn>/
    3. Callback URL: https://<openshift_dev_spaces_fqdn>/api/oauth/callback
    4. Deselect the Active check box in the Webhook section.
    5. Under Permissions & events, set the Contents repository permission to Read and Write.
  3. Click Create GitHub App.
  4. Click Generate a new client secret.
  5. Copy and save the GitHub App Client Secret for use when applying the GitHub App Secret.
  6. Copy and save the GitHub App Client ID for use when applying the GitHub App Secret.
  7. Install the GitHub App. See Installing your own GitHub App.

Verification

  • Verify that the GitHub App appears in your GitHub account under Settings Developer settings GitHub Apps.

13.3. Apply the GitHub OAuth App Secret

Prepare and apply the GitHub OAuth App Secret so that OpenShift Dev Spaces users can access remote Git repositories hosted on GitHub without re-entering credentials.

Prerequisites

  • You have configured the GitHub OAuth App.
  • You have the following values, which were generated when configuring the GitHub OAuth App:

    • GitHub OAuth Client ID
    • GitHub OAuth Client Secret
  • You have an active oc session with administrative permissions to the destination OpenShift cluster. See Getting started with the CLI.

Procedure

  1. Prepare the Secret:

    kind: Secret
    apiVersion: v1
    metadata:
      name: github-oauth-config
      namespace: openshift-devspaces
      labels:
        app.kubernetes.io/part-of: che.eclipse.org
        app.kubernetes.io/component: oauth-scm-configuration
      annotations:
        che.eclipse.org/oauth-scm-server: github
        che.eclipse.org/scm-server-endpoint: <github_server_url>
        che.eclipse.org/scm-github-disable-subdomain-isolation: 'false'
    type: Opaque
    stringData:
      id: <GitHub_OAuth_Client_ID>
      secret: <GitHub_OAuth_Client_Secret>

    where:

    namespace
    The OpenShift Dev Spaces namespace. The default is openshift-devspaces.
    che.eclipse.org/scm-server-endpoint
    This depends on the GitHub product your organization is using. When hosting repositories on GitHub.com or GitHub Enterprise Cloud, omit this line or enter the default https://github.com. When hosting repositories on GitHub Enterprise Server, enter the GitHub Enterprise Server URL.
    che.eclipse.org/scm-github-disable-subdomain-isolation
    If you are using GitHub Enterprise Server with a disabled subdomain isolation option, you must set the annotation to true. Otherwise, you can either omit the annotation or set it to false.
    id
    The GitHub OAuth Client ID.
    secret
    The GitHub OAuth Client Secret.
  2. Apply the Secret:

    $ oc apply -f - <<EOF
    <Secret_prepared_in_the_previous_step>
    EOF
  3. Optional: To configure OAuth 2.0 for another GitHub provider, repeat the previous steps and create a second GitHub OAuth Secret with a different name.

Verification

  • Verify that the output displays secret/github-oauth-config created.

13.4. Set up the GitLab authorized application

To enable users to work with a remote Git repository that is hosted using a GitLab instance, create the GitLab authorized application (OAuth 2.0).

Prerequisites

  • You are logged in to GitLab.

Procedure

  1. Click your avatar and go to Edit profile Applications.
  2. Enter OpenShift Dev Spaces as the Name.
  3. Enter https://<openshift_dev_spaces_fqdn>/api/oauth/callback as the Redirect URI.
  4. Check the Confidential and Expire access tokens checkboxes.
  5. Under Scopes, check the api, write_repository, and openid checkboxes.
  6. Click Save application.
  7. Copy and save the GitLab Application ID for use when applying the GitLab-authorized application Secret.
  8. Copy and save the GitLab Client Secret for use when applying the GitLab-authorized application Secret.

Prepare and apply the GitLab-authorized application Secret so that OpenShift Dev Spaces users can access remote Git repositories hosted on GitLab without re-entering credentials.

Prerequisites

  • You have configured the GitLab authorized application.
  • You have the following values, which were generated when configuring the GitLab authorized application:

    • GitLab Application ID
    • GitLab Client Secret
  • You have an active oc session with administrative permissions to the destination OpenShift cluster. See Getting started with the CLI.

Procedure

  1. Prepare the Secret:

    kind: Secret
    apiVersion: v1
    metadata:
      name: gitlab-oauth-config
      namespace: openshift-devspaces
      labels:
        app.kubernetes.io/part-of: che.eclipse.org
        app.kubernetes.io/component: oauth-scm-configuration
      annotations:
        che.eclipse.org/oauth-scm-server: gitlab
        che.eclipse.org/scm-server-endpoint: <gitlab_server_url>
    type: Opaque
    stringData:
      id: <GitLab_Application_ID>
      secret: <GitLab_Client_Secret>

    where:

    namespace
    The OpenShift Dev Spaces namespace. The default is openshift-devspaces.
    che.eclipse.org/scm-server-endpoint
    The GitLab server URL. Use https://gitlab.com for the SAAS version.
    id
    The GitLab Application ID.
    secret
    The GitLab Client Secret.
  2. Apply the Secret:

    $ oc apply -f - <<EOF
    <Secret_prepared_in_the_previous_step>
    EOF
  3. Optional: To configure OAuth 2.0 for another GitLab provider, repeat the previous steps and create a second GitLab OAuth Secret with a different name.

Verification

  • Verify that the output displays secret/gitlab-oauth-config created.

To enable users to work with a remote Git repository that is hosted in the Bitbucket Cloud, create an OAuth consumer (OAuth 2.0) in the Bitbucket Cloud.

Prerequisites

  • You are logged in to the Bitbucket Cloud.

Procedure

  1. Click your avatar and go to the All workspaces page.
  2. Select a workspace and click it.
  3. Go to Settings OAuth consumers Add consumer.
  4. Enter OpenShift Dev Spaces as the Name.
  5. Enter https://<openshift_dev_spaces_fqdn>/api/oauth/callback as the Callback URL.
  6. Under Permissions, check all of the Account and Repositories checkboxes, and click Save.
  7. Expand the added consumer and then copy and save the Key value for use when applying the Bitbucket OAuth consumer Secret.
  8. Copy and save the Secret value for use when applying the Bitbucket OAuth consumer Secret.

Prepare and apply the OAuth consumer Secret for Bitbucket Cloud so that OpenShift Dev Spaces users can access remote Git repositories hosted on Bitbucket Cloud without re-entering credentials.

Prerequisites

  • You have configured the OAuth consumer in the Bitbucket Cloud.
  • You have the following values, which were generated when configuring the Bitbucket OAuth consumer:

    • Bitbucket OAuth consumer Key
    • Bitbucket OAuth consumer Secret
  • You have an active oc session with administrative permissions to the destination OpenShift cluster. See Getting started with the CLI.

Procedure

  1. Prepare the Secret:

    kind: Secret
    apiVersion: v1
    metadata:
      name: bitbucket-oauth-config
      namespace: openshift-devspaces
      labels:
        app.kubernetes.io/part-of: che.eclipse.org
        app.kubernetes.io/component: oauth-scm-configuration
      annotations:
        che.eclipse.org/oauth-scm-server: bitbucket
    type: Opaque
    stringData:
      id: <Bitbucket_Oauth_Consumer_Key>
      secret: <Bitbucket_Oauth_Consumer_Secret>

    where:

    namespace
    The OpenShift Dev Spaces namespace. The default is openshift-devspaces.
    id
    The Bitbucket OAuth consumer Key.
    secret
    The Bitbucket OAuth consumer Secret.
  2. Apply the Secret:

    $ oc apply -f - <<EOF
    <Secret_prepared_in_the_previous_step>
    EOF

Verification

  • Verify that the output displays secret/bitbucket-oauth-config created.

13.12. Set up the Microsoft Entra ID OAuth App

Set up a Microsoft Entra ID OAuth App to enable OpenShift Dev Spaces users to interact with Azure DevOps Git repositories without re-entering credentials.

Prerequisites

Procedure

  1. Register an application in Microsoft Entra ID. See Register an application.
  2. Add the Authorization callback URL https://<openshift_dev_spaces_fqdn>/api/oauth/callback to your application. See Add a redirect URI.
  3. Add a client secret to your application. See Add credentials.
  4. Add the Azure DevOps vso.code_write permission to the client application. See Add permissions to access your web API.
  5. Connect your Azure DevOps organization to Microsoft Entra ID. See Connect your organization to Microsoft Entra ID.

Prepare and apply the Secret that enables OpenShift Dev Spaces to authenticate with Microsoft Entra ID for Azure DevOps repository access.

Prerequisites

  • You have configured the Microsoft Entra ID OAuth App.
  • You have the following values, which were generated when configuring the Microsoft Entra ID OAuth App:

    • Application (client) ID
    • Directory (tenant) ID
    • Client Secret
  • You have an active oc session with administrative permissions to the destination OpenShift cluster. See Getting started with the CLI.

Procedure

  1. Prepare the Secret:

    kind: Secret
    apiVersion: v1
    metadata:
      name: azure-devops-oauth-config
      namespace: openshift-devspaces
      labels:
        app.kubernetes.io/part-of: che.eclipse.org
        app.kubernetes.io/component: oauth-scm-configuration
      annotations:
        che.eclipse.org/oauth-scm-server: azure-devops
    type: Opaque
    stringData:
      tenant-id: <Microsoft_Entra_ID_Tenant_ID>
      id: <Microsoft_Entra_ID_App_ID>
      secret: <Microsoft_Entra_ID_Client_Secret>

    where:

    namespace
    The OpenShift Dev Spaces namespace. The default is openshift-devspaces.
    tenant-id
    The Microsoft Entra ID Directory (tenant) ID.
    id
    The Microsoft Entra ID Application (client) ID.
    secret
    The Microsoft Entra ID Client Secret.
  2. Apply the Secret:

    $ oc apply -f - <<EOF
    <Secret_prepared_in_the_previous_step>
    EOF

Verification

  • Verify that the output displays secret/azure-devops-oauth-config created.
  • Verify that the rollout of the OpenShift Dev Spaces server components is complete:

    $ oc rollout status deployment/devspaces -n openshift-devspaces

Enable an experimental feature that forces a refresh of the personal access token on workspace startup in Red Hat OpenShift Dev Spaces.

Important

This is an experimental feature.

Prerequisites

Procedure

  1. Modify the CheCluster Custom Resource to enable forced token refresh:

    spec:
      components:
        cheServer:
          extraProperties:
            CHE_FORCE_REFRESH_PERSONAL_ACCESS_TOKEN: "true"

Verification

  • Start a new workspace and verify that the personal access token is refreshed by checking the OpenShift Dev Spaces server logs.
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat Documentation

Legal Notice

Theme

© 2026 Red Hat
Back to top