• 設定例
  • Google の設定
  • Microsoft Azureの設定
  • Microsoft Azure Active Directory B2Cの設定
    • カスタムポリシーの設定
    • Azure B2C のトラブルシューティング
  • Keycloakの設定
    • 対称鍵アルゴリズムによるKeycloakの設定
  • カスドア
• 複数のOpenID Connectプロバイダーの設定
• OIDC グループメンバーシップに基づいたユーザーの設定
  • 必須グループ
  • 外部グループ
  • 監査役グループ
  • 管理者グループ
• トラブルシューティング

OAuth 2.0認証プロバイダとしてOpenID Connectを使用します。

GitLabはOpenIDConnectをOmniAuthプロバイダとして使用することができます。

OpenID Connect OmniAuthプロバイダを有効にするには、アプリケーションをOpenID Connectプロバイダに登録する必要があります。OpenID Connectはクライアントの詳細とシークレットを提供します。

1. GitLab サーバーで設定ファイルを開きます。

   Linuxパッケージ・インストールの場合：

   sudo editor /etc/gitlab/gitlab.rb
   

   セルフコンパイルによるインストールの場合：

   cd /home/git/gitlab
   sudo -u git -H editor config/gitlab.yml
   

2. 共通設定を構成して、シングルサインオンプロバイダとしてopenid_connect 。これにより、既存のGitLabアカウントを持っていないユーザーのためのJust-In-Timeアカウントプロビジョニングが可能になります。

3. プロバイダー設定を追加します。

   Linuxパッケージ・インストールの場合：

   gitlab_rails['omniauth_providers'] = [
     {
       name: "openid_connect", # do not change this parameter
       label: "Provider name", # optional label for login button, defaults to "Openid Connect"
       icon: "<custom_provider_icon>",
       args: {
         name: "openid_connect",
         scope: ["openid","profile","email"],
         response_type: "code",
         issuer: "<your_oidc_url>",
         discovery: true,
         client_auth_method: "query",
         uid_field: "<uid_field>",
         send_scope_to_token_endpoint: "false",
         pkce: true,
         client_options: {
           identifier: "<your_oidc_client_id>",
           secret: "<your_oidc_client_secret>",
           redirect_uri: "<your_gitlab_url>/users/auth/openid_connect/callback"
         }
       }
     }
   ]
   

   複数の ID プロバイダーを使用する Linux パッケージ・インストールの場合：

   { 'name' => 'openid_connect',
     'label' => '...',
     'icon' => '...',
     'args' => {
       'name' => 'openid_connect',
       'strategy_class': 'OmniAuth::Strategies::OpenIDConnect',
       'scope' => ['openid', 'profile', 'email'],
       'discovery' => true,
       'response_type' => 'code',
       'issuer' => 'https://...',
       'client_auth_method' => 'query',
       'uid_field' => '...',
       'client_options' => {
         `identifier`: "<your_oidc_client_id>",
         `secret`: "<your_oidc_client_secret>",
         'redirect_uri' => 'https://.../users/auth/openid_connect/callback'
      }
    }
   },
   { 'name' => 'openid_connect_2fa',
     'label' => '...',
     'icon' => '...',
     'args' => {
       'name' => 'openid_connect_2fa',
       'strategy_class': 'OmniAuth::Strategies::OpenIDConnect',
       'scope' => ['openid', 'profile', 'email'],
       'discovery' => true,
       'response_type' => 'code',
       'issuer' => 'https://...',
       'client_auth_method' => 'query',
       'uid_field' => '...',
       'client_options' => {
        ...
        'redirect_uri' => 'https://.../users/auth/openid_connect_2fa/callback'
      }
    }
   }
   

   OIDC で複数の ID プロバイダを使用する場合の詳細については、イシュー5992 を参照してください。

   セルフコンパイルによるインストールの場合：

     - { name: 'openid_connect', # do not change this parameter
         label: 'Provider name', # optional label for login button, defaults to "Openid Connect"
         icon: '<custom_provider_icon>',
         args: {
           name: 'openid_connect',
           scope: ['openid','profile','email'],
           response_type: 'code',
           issuer: '<your_oidc_url>',
           discovery: true,
           client_auth_method: 'query',
           uid_field: '<uid_field>',
           send_scope_to_token_endpoint: false,
           pkce: true,
           client_options: {
             identifier: '<your_oidc_client_id>',
             secret: '<your_oidc_client_secret>',
             redirect_uri: '<your_gitlab_url>/users/auth/openid_connect/callback'
           }
         }
       }
   

   各設定オプションの詳細については、OmniAuth OpenID Connect usage documentationおよびOpenID Connect Core 1.0 specification を参照してください。

4. プロバイダの設定では、OpenID Connectクライアントの設定に合わせてプロバイダの値を変更します。以下を参考にしてください：

   • <your_oidc_label> はログインページに表示されるラベルです。
   • <custom_provider_icon> (オプション) はログインページに表示されるアイコンです。主要なソーシャルログインプラットフォームのアイコンはGitLabに組み込まれていますが、このパラメータを指定することでこれらのアイコンを上書きすることができます。GitLabはローカルパスと絶対URLの両方を受け入れます。
   • <your_oidc_url> (オプション)はOpenID Connectプロバイダを指すURLです(例えばhttps://example.com/auth/realms/your-realm)。この値が提供されない場合、URLは以下のフォーマットでclient_options から構築されます:<client_options.scheme>://<client_options.host>:<client_options.port>.
   • discovery がtrue に設定されている場合、OpenID Connect プロバイダは<your_oidc_url>/.well-known/openid-configuration を使用してクライアントオプションの自動検出を試みます。デフォルトはfalseです。
   • client_auth_method (オプション) は、OpenID Connect プロバイダとクライアントの認証に使用する方法を指定します。
     • 使用可能な値は以下のとおりです：
       • basic - HTTP 基本認証。
       • jwt_bearer - JWTベースの認証（秘密鍵とクライアントシークレットの署名）。
       • mtls - 相互TLSまたはX.509証明書の検証。
       • それ以外の値では、リクエストボディにクライアントIDとシークレットを投稿します。
     • 指定されない場合、この値のデフォルトはbasic です。
   • <uid_field> (オプション) は、uid の値を定義するuser_info.raw_attributes のフィールド名です (例:preferred_username)。この値を指定しない場合、または設定された値を持つフィールドがuser_info.raw_attributes の詳細にない場合、uid はsub フィールドを使用します。
   • send_scope_to_token_endpoint はデフォルトでtrue です。したがって、このscope パラメータは通常、トークン・エンドポイントへのリクエストに含ま scopeれます。ただし、scope OpenID Connectプロバイダがこの scopeようなリクエストでパラメータをscope 受け付けない scope場合は、これをfalseに設定してください。
   • pkce (オプション）：Proof Key for Code Exchangeを有効にします。GitLab 15.9で利用可能。
   • client_options はOpenID Connectクライアント固有のオプションです。具体的には
     • identifier は、OpenID Connect サービスプロバイダで設定されているクライアント識別子です。
     • secret は、OpenID Connect サービスプロバイダで設定されているクライアントシークレットです。たとえば、OmniAuth OpenID Connectではこれが必要です。サービスプロバイダがシークレットを必要としない場合は、任意の値を指定しても無視されます。
     • redirect_uri はログイン成功後にユーザーをリダイレクトするGitLabのURLです（例えば、http://example.com/users/auth/openid_connect/callback ）。
     • end_session_endpoint (オプション) は、セッションを終了するエンドポイントへの URL です。自動検出が無効または失敗した場合にこのURLを指定できます。
     • 自動検出が無効または失敗しない限り、以下のclient_options はオプションです：
       • authorization_endpoint は、エンドユーザーを作成するエンドポイントへの URL です。
       • token_endpoint は、アクセストークンを提供するエンドポイントへの URL です。
       • userinfo_endpoint はユーザー情報を提供するエンドポイントへのURLです。
       • jwks_uri は、トークン署名者が鍵を公開するエンドポイントへの URL です。
5. 設定ファイルを保存します。

6. 変更を有効にするには

   • Linux パッケージを使用して GitLab をインストールした場合は、GitLab を再設定してください。
   • インストールしたGitLabをセルフコンパイルし、GitLabを再起動。

サインインページでは、通常のサインインフォームの下にOpenID Connectオプションがあります。このオプションを選択して認証プロセスを開始します。OpenID Connectプロバイダーは、GitLabアプリケーションにサインインし、クライアントによって確認が必要な場合は作成者を尋ねます。GitLabにリダイレクトされ、サインインします。

設定例

以下の設定は、Linux パッケージインストールを使用する際に、異なるプロバイダで OpenID を設定する方法を示しています。

Google の設定

詳しくはGoogleのドキュメントをご覧ください：

gitlab_rails['omniauth_providers'] = [
  {
    name: "openid_connect", # do not change this parameter
    label: "Google OpenID", # optional label for login button, defaults to "Openid Connect"
    args: {
      name: "openid_connect",
      scope: ["openid", "profile", "email"],
      response_type: "code",
      issuer: "https://accounts.google.com",
      client_auth_method: "query",
      discovery: true,
      uid_field: "preferred_username",
      pkce: true,
      client_options: {
        identifier: "<YOUR PROJECT CLIENT ID>",
        secret: "<YOUR PROJECT CLIENT SECRET>",
        redirect_uri: "https://example.com/users/auth/openid_connect/callback",
       }
     }
  }
]

Microsoft Azureの設定

Microsoft Azure用のOpenID Connect(OIDC) プロトコルは、Microsoftアイデンティティプラットフォーム（v2）エンドポイントを使用します。開始するには、Azureポータルにサインインします。アプリには、以下の情報が必要です：

• テナント ID。すでにお持ちの場合もあります。詳細については、Microsoft Azureテナントのドキュメントを参照してください。
• クライアント ID とクライアントシークレット。Microsoft Quickstart Register an Applicationドキュメントの指示に従って、アプリのテナント ID、クライアント ID、クライアント シークレットを取得します。

Linuxパッケージインストール用の設定ブロック例：

gitlab_rails['omniauth_providers'] = [
  {
    name: "openid_connect", # do not change this parameter
    label: "Azure OIDC", # optional label for login button, defaults to "Openid Connect"
    args: {
      name: "openid_connect",
      scope: ["openid", "profile", "email"],
      response_type: "code",
      issuer:  "https://login.microsoftonline.com/<YOUR-TENANT-ID>/v2.0",
      client_auth_method: "query",
      discovery: true,
      uid_field: "preferred_username",
      pkce: true,
      client_options: {
        identifier: "<YOUR APP CLIENT ID>",
        secret: "<YOUR APP CLIENT SECRET>",
        redirect_uri: "https://gitlab.example.com/users/auth/openid_connect/callback"
      }
    }
  }
]

マイクロソフトはそのプラットフォームがOIDCプロトコルでどのように動作するかを文書化しています。

Microsoft Azure Active Directory B2Cの設定

GitLabがAzure Active Directory B2Cと連携するには特別な設定が必要です。始めるには、Azureポータルにサインインします。アプリには、Azureから以下の情報が必要です：

• テナントID。テナント ID。詳細については、Microsoft Azure Tenantドキュメントをレビューしてください。
• クライアント ID とクライアント シークレット。Microsoft チュートリアルドキュメントの指示に従って、アプリのクライアント ID とクライアント シークレットを取得します。
• ユーザーフローまたはポリシー名。Microsoftチュートリアルの指示に従ってください。

アプリを設定します：

1. アプリをRedirect URI に設定します。例えば、GitLabドメインがgitlab.example.com の場合、アプリRedirect URI をhttps://gitlab.example.com/users/auth/openid_connect/callback に設定します。

2. IDトークンを有効にします。

3. アプリに以下のAPI権限を追加します：

   • openid
   • offline_access

カスタムポリシーの設定

Azure B2Cでは、ユーザーをログインさせるためのビジネスロジックを定義する2つの方法があります：

• ユーザーフロー
• カスタムポリシー

標準の Azure B2C ユーザーフローでは、OpenIDemail クレームを送信しないため、カスタムポリシーが必要です。したがって、標準のユーザーフローは、allow_single_sign_on またはauto_link_user パラメータでは動作しません。標準の Azure B2C ポリシーでは、GitLab は新しいアカウントを作成したり、メールアドレスを使用して既存のアカウントにリンクしたりできません。

まず、カスタムポリシーを作成します。

Microsoftの説明では、カスタムポリシースターターパックのSocialAndLocalAccounts 、LocalAccounts 、ローカルのActive Directoryアカウントに対して認証を行います。ポリシーをアップロードする前に、以下を実行してください：

1. email クレームをエクスポートするには、SignUpOrSignin.xml を変更します。 次の行を置き換えます：

   <OutputClaim ClaimTypeReferenceId="email" />
   

   に置き換えてください：

   <OutputClaim ClaimTypeReferenceId="signInNames.emailAddress" PartnerClaimType="email" />
   

2. OIDCディスカバリーをB2Cで動作させるには、OIDC仕様と互換性のある発行者でポリシーを設定してください。トークンの互換性設定を参照してください。JwtIssuer の下のTrustFrameworkBase.xml で、IssuanceClaimPattern をAuthorityWithTfpに設定します：

   <ClaimsProvider>
     <DisplayName>Token Issuer</DisplayName>
     <TechnicalProfiles>
       <TechnicalProfile Id="JwtIssuer">
         <DisplayName>JWT Issuer</DisplayName>
         <Protocol Name="None" />
         <OutputTokenFormat>JWT</OutputTokenFormat>
         <Metadata>
           <Item Key="IssuanceClaimPattern">AuthorityWithTfp</Item>
           ...
   

3. ポリシーをアップロードします。既存のポリシーを更新する場合は、既存のファイルを上書きします。

4. 発行者 URL を決定するには、サインインポリシーを使用します。発行者 URL は次の形式です：

   https://<YOUR-DOMAIN>/tfp/<YOUR-TENANT-ID>/<YOUR-SIGN-IN-POLICY-NAME>/v2.0/
   

   ポリシー名は URL の小文字になります。たとえば、B2C_1A_signup_signin ポリシーは、b2c_1a_signup_sigin と表示されます。

   末尾のスラッシュが含まれていることを確認してください。

5. OIDCディスカバリーURLと発行者URLのオペレーションを確認し、発行者URLに.well-known/openid-configuration ：

   https://<YOUR-DOMAIN>/tfp/<YOUR-TENANT-ID>/<YOUR-SIGN-IN-POLICY-NAME>/v2.0/.well-known/openid-configuration
   

   たとえば、domain がexample.b2clogin.com で、テナント ID がfc40c736-476c-4da1-b489-ee48cee84386 の場合、curl とjq を使って発行者を抽出できます：

   $ curl --silent "https://example.b2clogin.com/tfp/fc40c736-476c-4da1-b489-ee48cee84386/b2c_1a_signup_signin/v2.0/.well-known/openid-configuration" | jq .issuer
   "https://example.b2clogin.com/tfp/fc40c736-476c-4da1-b489-ee48cee84386/b2c_1a_signup_signin/v2.0/"
   

6. signup_signin で使用したカスタムポリシーで発行者の URL を設定します。たとえば、これは Linux パッケージインストール用のb2c_1a_signup_signin のカスタムポリシーによる設定です：

   gitlab_rails['omniauth_providers'] = [
   {
     name: "openid_connect", # do not change this parameter
     label: "Azure B2C OIDC", # optional label for login button, defaults to "Openid Connect"
     args: {
       name: "openid_connect",
       scope: ["openid"],
       response_mode: "query",
       response_type: "id_token",
       issuer:  "https://<YOUR-DOMAIN>/tfp/<YOUR-TENANT-ID>/b2c_1a_signup_signin/v2.0/",
       client_auth_method: "query",
       discovery: true,
       send_scope_to_token_endpoint: true,
       pkce: true,
       client_options: {
         identifier: "<YOUR APP CLIENT ID>",
         secret: "<YOUR APP CLIENT SECRET>",
         redirect_uri: "https://gitlab.example.com/users/auth/openid_connect/callback"
       }
     }
   }]
   

Azure B2C のトラブルシューティング

• yourtenant.onmicrosoft.com 、ProxyIdentityExperienceFrameworkAppId 、およびIdentityExperienceFrameworkAppId がすべて、B2C テナントのホスト名と、XML ポリシー ファイルの各クライアント ID と一致していることを確認します。
• アプリにリダイレクト URI としてhttps://jwt.ms を追加し、カスタムポリシーテスターを使用します。ペイロードにユーザーのメールアクセスと一致するemail が含まれていることを確認してください。

• カスタムポリシーを有効にした後、ユーザーがサインインしようとするとInvalid username or password が表示される場合があります。これは、IdentityExperienceFramework アプリの設定の問題である可能性があります。アプリのマニフェストにこれらの設定が含まれていることを確認することを示唆するMicrosoft のコメントを参照してください：

  • "accessTokenAcceptedVersion": null
  • "signInAudience": "AzureADMyOrg"

この設定は、IdentityExperienceFramework アプリの作成時に使用されたSupported account types 設定に対応しています。

Keycloakの設定

GitLabはHTTPSを使用するOpenIDプロバイダと連携します。HTTPを使うKeycloakサーバーを設定することもできますが、GitLabはHTTPSを使うKeycloakサーバーとしか通信できません。

トークンに署名するために対称鍵暗号化アルゴリズム（例えばHS256やHS358）の代わりに公開鍵暗号化アルゴリズム（例えばRSA256やRSA512）を使用するようにKeycloakを設定します。公開鍵暗号化アルゴリズムは次のとおりです：

• 設定が簡単。
• 秘密鍵の漏洩はセキュリティに深刻な影響を与えるため、より安全。

1. Keycloakの管理コンソールを開きます。
2. Realm Settings > Tokens > Default Signature Algorithmを選択します。
3. 署名アルゴリズムを設定します。

Linuxパッケージインストール用の設定ブロック例：

gitlab_rails['omniauth_providers'] = [
  {
    name: "openid_connect", # do not change this parameter
    label: "Keycloak", # optional label for login button, defaults to "Openid Connect"
    args: {
      name: "openid_connect",
      scope: ["openid", "profile", "email"],
      response_type: "code",
      issuer:  "https://keycloak.example.com/realms/myrealm",
      client_auth_method: "query",
      discovery: true,
      uid_field: "preferred_username",
      pkce: true,
      client_options: {
        identifier: "<YOUR CLIENT ID>",
        secret: "<YOUR CLIENT SECRET>",
        redirect_uri: "https://gitlab.example.com/users/auth/openid_connect/callback"
      }
    }
  }
]

対称鍵アルゴリズムによるKeycloakの設定

GitLab 14.2で導入されました。

共通鍵暗号化を使うには：

1. Keycloakデータベースからシークレットキーを抽出します。Keycloakはこの値をウェブインターフェースでは公開しません。ウェブインターフェースに表示されるクライアントシークレットはOAuth 2.0のクライアントシークレットであり、JSONウェブトークンに署名するために使用されるシークレットとは異なります。

   例えば、KeycloakのバックエンドデータベースとしてPostgreSQLを使用する場合：

   • データベースコンソールにサインインします。

   • 次の SQL クエリを実行してキーを抽出します：

      $ psql -U keycloak
      psql (13.3 (Debian 13.3-1.pgdg100+1))
      Type "help" for help.
           
      keycloak=# SELECT c.name, value FROM component_config CC INNER JOIN component C ON(CC.component_id = C.id) WHERE C.realm_id = 'master' and provider_id = 'hmac-generated' AND CC.name = 'secret';
      -[ RECORD 1 ]---------------------------------------------------------------------------------
      name  | hmac-generated
      value | lo6cqjD6Ika8pk7qc3fpFx9ysrhf7E62-sqGc8drp3XW-wr93zru8PFsQokHZZuJJbaUXvmiOftCZM3C4KW3-g
      -[ RECORD 2 ]---------------------------------------------------------------------------------
      name  | fallback-HS384
      value | UfVqmIs--U61UYsRH-NYBH3_mlluLONpg_zN7CXEwkJcO9xdRNlzZfmfDLPtf2xSTMvqu08R2VhLr-8G-oZ47A
     

     この例では、HS256 (hmac-generated) と HS384 (fallback-HS384) の二つの秘密鍵があります。最初のvalue を使って GitLab を設定します。

2. value を標準の base64 に変換します。HS256トークンによる無効な署名の投稿で説明したように、value は RFC 4648 のURL とファイル名の安全なアルファベットによる Base 64 エンコーディングのセクションでエンコードされています。これはRFC 2045で定義されている標準のbase64に変換する必要があります。以下のRubyスクリプトがこれを行います：

   require 'base64'
      
   value = "lo6cqjD6Ika8pk7qc3fpFx9ysrhf7E62-sqGc8drp3XW-wr93zru8PFsQokHZZuJJbaUXvmiOftCZM3C4KW3-g"
   Base64.encode64(Base64.urlsafe_decode64(value))
   

   この結果、以下の値が得られます：

   lo6cqjD6Ika8pk7qc3fpFx9ysrhf7E62+sqGc8drp3XW+wr93zru8PFsQokH\nZZuJJbaUXvmiOftCZM3C4KW3+g==\n
   

3. この base64 エンコードされたシークレットをjwt_secret_base64 で指定します。例えば

   gitlab_rails['omniauth_providers'] = [
     {
       name: "openid_connect", # do not change this parameter
       label: "Keycloak", # optional label for login button, defaults to "Openid Connect"
       args: {
         name: "openid_connect",
         scope: ["openid", "profile", "email"],
         response_type: "code",
         issuer:  "https://keycloak.example.com/auth/realms/myrealm",
         client_auth_method: "query",
         discovery: true,
         uid_field: "preferred_username",
         jwt_secret_base64: "<YOUR BASE64-ENCODED SECRET>",
         pkce: true,
         client_options: {
           identifier: "<YOUR CLIENT ID>",
           secret: "<YOUR CLIENT SECRET>",
           redirect_uri: "https://gitlab.example.com/users/auth/openid_connect/callback"
         }
       }
     }
   ]
   

JSON::JWS::VerificationFailed エラーが表示された場合は、シークレットの指定が間違っています。

カスドア

GitLabはHTTPSを使用するOpenIDプロバイダと連携しています。CasdoorでOpenIDを通してGitLabに接続するにはHTTPSを使用してください。

あなたのアプリのために、Casdoorで以下のステップを完了してください：

1. クライアントIDとクライアントシークレットを取得します。
2. GitLabのリダイレクトURLを追加します。例えば、GitLab のドメインがgitlab.example.com の場合、Casdoor アプリがRedirect URI:https://gitlab.example.com/users/auth/openid_connect/callback のようになっていることを確認します。

詳細はCasdoorのドキュメントを参照してください。

Linuxパッケージインストール時の設定例（ファイルパス：/etc/gitlab/gitlab.rb ）：

gitlab_rails['omniauth_providers'] = [
    {
        name: "openid_connect", # do not change this parameter
        label: "Casdoor", # optional label for login button, defaults to "Openid Connect"
        args: {
            name: "openid_connect",
            scope: ["openid", "profile", "email"],
            response_type: "code",
            issuer:  "https://<CASDOOR_HOSTNAME>",
            client_auth_method: "query",
            discovery: true,
            uid_field: "sub",
            client_options: {
                identifier: "<YOUR CLIENT ID>",
                secret: "<YOUR CLIENT SECRET>",
                redirect_uri: "https://gitlab.example.com/users/auth/openid_connect/callback"
            }
        }
    }
]

セルフ・コンパイル・インストールの設定例 (ファイル・パス:config/gitlab.yml)：

  - { name: 'openid_connect', # do not change this parameter
      label: 'Casdoor', # optional label for login button, defaults to "Openid Connect"
      args: {
        name: 'openid_connect',
        scope: ['openid','profile','email'],
        response_type: 'code',
        issuer: 'https://<CASDOOR_HOSTNAME>',
        discovery: true,
        client_auth_method: 'query',
        uid_field: 'sub',
        client_options: {
          identifier: '<YOUR CLIENT ID>',
          secret: '<YOUR CLIENT SECRET>',
          redirect_uri: 'https://gitlab.example.com/users/auth/openid_connect/callback'
        }
      }
    }

複数のOpenID Connectプロバイダーの設定

アプリケーションで複数の OpenID Connect(OIDC) プロバイダを使用するように設定できます。そのためには、設定ファイルでstrategy_class を明示的に設定します。

これは、以下のいずれかのシナリオで行う必要があります：

• OpenID Connectプロトコルへのマイグレーション。
• さまざまな認証レベルの提供

以下の設定例では、2FA を使用するオプションと 2FA を使用しないオプションという、異なるレベルの認証を提供する方法を示しています。

Linuxパッケージ・インストールの場合：

gitlab_rails['omniauth_providers'] = [
  {
    name: "openid_connect",
    label: "Provider name", # optional label for login button, defaults to "Openid Connect"
    icon: "<custom_provider_icon>",
    args: {
      name: "openid_connect",
      strategy_class: "OmniAuth::Strategies::OpenIDConnect",
      scope: ["openid","profile","email"],
      response_type: "code",
      issuer: "<your_oidc_url>",
      discovery: true,
      client_auth_method: "query",
      uid_field: "<uid_field>",
      send_scope_to_token_endpoint: "false",
      pkce: true,
      client_options: {
        identifier: "<your_oidc_client_id>",
        secret: "<your_oidc_client_secret>",
        redirect_uri: "<your_gitlab_url>/users/auth/openid_connect/callback"
      }
    }
  },
  {
    name: "openid_connect_2fa",
    label: "Provider name 2FA", # optional label for login button, defaults to "Openid Connect"
    icon: "<custom_provider_icon>",
    args: {
      name: "openid_connect_2fa",
      strategy_class: "OmniAuth::Strategies::OpenIDConnect",
      scope: ["openid","profile","email"],
      response_type: "code",
      issuer: "<your_oidc_url>",
      discovery: true,
      client_auth_method: "query",
      uid_field: "<uid_field>",
      send_scope_to_token_endpoint: "false",
      pkce: true,
      client_options: {
        identifier: "<your_oidc_client_id>",
        secret: "<your_oidc_client_secret>",
        redirect_uri: "<your_gitlab_url>/users/auth/openid_connect_2fa/callback"
      }
    }
  }
]

セルフコンパイルによるインストールの場合：

  - { name: 'openid_connect',
      label: 'Provider name', # optional label for login button, defaults to "Openid Connect"
      icon: '<custom_provider_icon>',
      args: {
        name: 'openid_connect',
        strategy_class: "OmniAuth::Strategies::OpenIDConnect",
        scope: ['openid','profile','email'],
        response_type: 'code',
        issuer: '<your_oidc_url>',
        discovery: true,
        client_auth_method: 'query',
        uid_field: '<uid_field>',
        send_scope_to_token_endpoint: false,
        pkce: true,
        client_options: {
          identifier: '<your_oidc_client_id>',
          secret: '<your_oidc_client_secret>',
          redirect_uri: '<your_gitlab_url>/users/auth/openid_connect/callback'
        }
      }
    }
  - { name: 'openid_connect_2fa',
      label: 'Provider name 2FA', # optional label for login button, defaults to "Openid Connect"
      icon: '<custom_provider_icon>',
      args: {
        name: 'openid_connect_2fa',
        strategy_class: "OmniAuth::Strategies::OpenIDConnect",
        scope: ['openid','profile','email'],
        response_type: 'code',
        issuer: '<your_oidc_url>',
        discovery: true,
        client_auth_method: 'query',
        uid_field: '<uid_field>',
        send_scope_to_token_endpoint: false,
        pkce: true,
        client_options: {
          identifier: '<your_oidc_client_id>',
          secret: '<your_oidc_client_secret>',
          redirect_uri: '<your_gitlab_url>/users/auth/openid_connect_2fa/callback'
        }
      }
    }

この使用例では、企業ディレクトリ内の既存の既知の識別子に基づいて、異なるプロバイダ間でextern_uid を同期したい場合があります。

これを行うには、uid_field を設定します。 次のコード例では、この方法を示しています：

def sync_missing_provider(self, user: User, extern_uid: str)
  existing_identities = []
  for identity in user.identities:
      existing_identities.append(identity.get("provider"))

  local_extern_uid = extern_uid.lower()
  for provider in ("openid_connect_2fa", "openid_connect"):
      identity = [
          identity
          for identity in user.identities
          if identity.get("provider") == provider
          and identity.get("extern_uid").lower() != local_extern_uid
      ]
      if provider not in existing_identities or identity:
          if identity and identity[0].get("extern_uid") != "":
              logger.error(f"Found different identity for provider {provider} for user {user.id}")
              continue
          else:
              logger.info(f"Add identity 'provider': {provider}, 'extern_uid': {extern_uid} for user {user.id}")
              user.provider = provider
              user.extern_uid = extern_uid
              user = self.save_user(user)
  return user

詳細はGitLab API ユーザーメソッドのドキュメント を参照ください。

OIDC グループメンバーシップに基づいたユーザーの設定

GitLab 15.10 で導入されました。

OIDCグループメンバーシップを設定することができます：

• ユーザーに特定のグループのメンバーであることを要求します。
• グループのメンバーに基づいて、ユーザーに外部、管理者、監査役のロールを割り当てます。

GitLabはサインインするたびにこれらのグループをチェックし、必要に応じてユーザー属性を更新します。この機能では、ユーザーを自動的にGitLabグループに追加することはできません。

必須グループ

アイデンティティ・プロバイダ（IdP）は、OIDCレスポンスでグループ情報をGitLabに渡す必要があります。このレスポンスを使ってユーザーに特定のグループのメンバーであることを要求するには、GitLabを識別するように設定します：

• groups_attribute 設定を使用して、OIDC レスポンスでグループを探す場所。
• required_groups 設定を使用して、サインインに必要なグループメンバーシップ。

required_groups を設定しないか、設定を空のままにすると、OIDC を通じて IdP によって認証されたユーザーであれば誰でも GitLab を使用できます。

外部グループ

IdPはOIDCレスポンスでグループ情報をGitLabに渡す必要があります。このレスポンスを使用して、グループメンバーシップに基づいてユーザーを外部ユーザーとして識別するには、GitLabを識別するように設定します：

• groups_attribute 設定を使用して、OIDC レスポンスでグループを探す場所。
• external_groups 設定を使用して、どのグループ・メンバーシップでユーザーを内部ユーザーとして識別するか。

監査役グループ

IdP は、OIDC レスポンスでグループ情報を GitLab に渡す必要があります。このレスポンスを使用して、グループメンバーシップに基づいてユーザーを監査役として割り当てるには、GitLabを識別するように設定します：

• groups_attribute 設定を使用して、OIDC レスポンスでグループを探す場所。
• auditor_groups 設定を使用して、どのグループ・メンバーシップがユーザーに監査役アクセスを許可するか。

管理者グループ

IdP は、OIDC レスポンスで GitLab にグループ情報を渡す必要があります。グループメンバーシップに基づいてユーザーを管理者として割り当てるためにこのレスポンスを使用するには、GitLabを識別するように設定します：

• groups_attribute 設定を使用して、OIDC レスポンスでグループを探す場所。
• admin_groups 設定を使用して、どのグループ・メンバーシップがユーザーに管理者アクセス権を付与するか。

トラブルシューティング

1. discovery がtrue に設定されていることを確認してください。false に設定した場合は、OpenID を動作させるために必要なすべての URL とキーを指定する必要があります。

2. システム時計を確認し、時刻が正しく同期されていることを確認します。

3. OmniAuth OpenID Connect のドキュメントに記載されているように、issuer がディスカバリ URL のベース URL に対応していることを確認してください。例えば、https://accounts.google.com は URLhttps://accounts.google.com/.well-known/openid-configurationに使用されます。

4. client_auth_method が定義されていない場合、またはbasicに設定されている場合、OpenID Connect クライアントは HTTP 基本認証を使用して OAuth 2.0 アクセストークンを送信します。userinfo エンドポイントを取得する際に 401 エラーが表示される場合は、OpenID Web サーバーの設定を確認してください。例えば、oauth2-server-phpの場合、Apache に設定パラメータを追加する必要があるかもしれません。