このコンテンツは選択した言語では利用できません。

Chapter 16. 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.

16.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.

16.2. 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.

16.3. 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.

16.4. Apply 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.

16.7. Set up an OAuth consumer in the Bitbucket Cloud

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.

16.8. Apply an OAuth consumer Secret for the Bitbucket Cloud

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.

16.11. 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.

16.12. Apply the Microsoft Entra ID OAuth App Secret

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

16.13. Force a refresh of the personal access token

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

詳細情報

試用、購入および販売

コミュニティー

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

Red Hat ドキュメントについて

Legal Notice

Theme

© 2026 Red Hat
トップに戻る