正式なドキュメントは英語版であり、この日本語訳はAI支援翻訳により作成された参考用のものです。日本語訳の一部の内容は人間によるレビューがまだ行われていないため、翻訳のタイミングにより英語版との間に差異が生じることがあります。最新かつ正確な情報については、英語版をご参照ください。

GitLabをOAuth 2.0認証用のIdentity Providerとして設定する

OAuth 2.0は、リソースオーナーに代わって、クライアントアプリケーションに対し、サーバーリソースへのアクセス権を安全に委任できる仕組みを提供します。OAuth 2を使用すると、認可サーバーがリソースオーナーまたはエンドユーザーの承認を得て、サードパーティクライアントにアクセストークンを発行できます。

インスタンスに次の種類のOAuth 2アプリケーションを追加することで、GitLabをOAuth 2認証用のIdentity Providerとして使用できます:

これらの方式の違いは、権限レベルのみです。デフォルトのコールバックURLは、SSL URLのhttps://your-gitlab.example.com/users/auth/gitlab/callbackです。非SSL URLを使用することもできますが、SSL URLの使用を推奨します。

インスタンスにOAuth 2アプリケーションを追加した後、OAuth 2を使用して次のことを行えます:

  • ユーザーがGitLab.comアカウントでアプリケーションにサインインできるようにする。
  • SAMLが関連付けられたグループに設定されている場合、SAML SSOを使用してユーザーがアプリケーションにサインインできるようにします。
  • GitLabインスタンスへの認証にGitLab.comを使用できるように設定する。詳細については、サーバーとGitLab.comの連携を参照してください。
  • アプリケーションを作成すると、外部サービスはOAuth 2 APIを使用してアクセストークンを管理できます。

ユーザーが所有するアプリケーションを作成する

ユーザーの新しいアプリケーションを作成するには、次の手順に従います:

  1. 左側のサイドバーで、アバターを選択します。

  2. プロファイルの編集を選択します。

  3. 左側のサイドバーで、アプリケーションを選択します。

  4. 新しいアプリケーションを追加を選択します。

  5. 名前とリダイレクトURIを入力します。

  6. 許可したアプリケーションで定義されているように、OAuth 2のスコープを選択します。

  7. リダイレクトURIに、ユーザーがGitLabで認証した後に転送されるURLを入力します。

  8. アプリケーションを保存を選択します。GitLabは以下を提供します:

    • アプリケーションIDフィールドに表示されるOAuth 2クライアントID。
    • OAuth 2クライアントシークレット。シークレットフィールドでコピーを選択することでアクセスできます。
    • シークレットを更新する機能（GitLab 15.9以降）。この機能を使用すると、このアプリケーションの新しいシークレットを生成し、コピーできます。シークレットを更新すると、認証情報が更新されるまで、既存のアプリケーションは機能しなくなります。

グループが所有するアプリケーションを作成する

グループの新しいアプリケーションを作成するには、次の手順に従います:

  1. 目的のグループに移動します。

  2. 左側のサイドバーで、設定 > アプリケーションを選択します。

  3. 名前とリダイレクトURIを入力します。

  4. 許可したアプリケーションで定義されているように、OAuth 2のスコープを選択します。

  5. リダイレクトURIに、ユーザーがGitLabで認証した後に転送されるURLを入力します。

  6. アプリケーションを保存を選択します。GitLabは以下を提供します:

    • アプリケーションIDフィールドに表示されるOAuth 2クライアントID。
    • OAuth 2クライアントシークレット。シークレットフィールドでコピーを選択することでアクセスできます。
    • シークレットを更新する機能（GitLab 15.9以降）。この機能を使用すると、このアプリケーションの新しいシークレットを生成し、コピーできます。シークレットを更新すると、認証情報が更新されるまで、既存のアプリケーションは機能しなくなります。

インスタンス全体で使用されるアプリケーションを作成する

  • プラン: Free、Premium、Ultimate
  • 提供形態: GitLab Self-Managed

GitLabインスタンスのアプリケーションを作成するには、次の手順に従います:

  1. 左側のサイドバーの下部で、管理者を選択します。
  2. アプリケーションを選択します。
  3. New application（新しいアプリケーション）を選択します。

管理者エリアでアプリケーションを作成する場合は、trusted（信用済み）としてマークします。このアプリケーションでは、ユーザー認可ステップは自動的にスキップされます。

許可したアプリケーションをすべて確認する

GitLab認証情報を使用して許可したすべてのアプリケーションを表示するには、次の手順に従います:

  1. 左側のサイドバーで、アバターを選択します。
  2. プロファイルの編集を選択し、次にアプリケーションを選択します。
  3. 許可したアプリケーションセクションを確認します。

GitLab OAuth 2アプリケーションはスコープをサポートしており、アプリケーションが実行するさまざまなアクションを制御できます。使用可能なすべてのスコープについては、次の表を参照してください。

スコープ説明
apiAPIへの完全な読み取り/書き込みアクセスを許可します。このアクセスの対象には、すべてのグループとプロジェクト、コンテナレジストリ、依存プロキシ、パッケージレジストリが含まれます。
read_apiAPIへの読み取りアクセスを許可します。このアクセスの対象には、すべてのグループとプロジェクト、コンテナレジストリ、パッケージレジストリが含まれます。
read_user/user APIエンドポイントを介して、認証済みユーザーのプロファイルへの読み取り専用アクセスを許可します。これには、ユーザー名、公開メール、および氏名が含まれます。また、/usersにある読み取り専用APIエンドポイントへのアクセスも許可します。
create_runnerrunnerへの作成アクセス権を付与します。
manage_runnerrunnerを管理するためのアクセス権を付与します。
k8s_proxyKubernetesエージェントを使用してKubernetes APIコールを実行する権限を付与します。
read_repositoryHTTP経由のGitまたはリポジトリファイルAPIを使用して、プライベートプロジェクトのリポジトリへの読み取り専用アクセスを許可します。
write_repositoryHTTP経由のGit（APIは使用しない）を使用して、プライベートプロジェクトのリポジトリへの読み取り/書き込みアクセスを許可します。
read_registryプライベートプロジェクトのコンテナレジストリ内のイメージへの読み取り専用アクセスを許可します。
write_registryプライベートプロジェクトで、コンテナレジストリイメージへの書き込みアクセスを許可します。イメージをプッシュするには、読み取りアクセスと書き込みアクセスの両方が必要です。
read_virtual_registryプライベートプロジェクトおよび仮想レジストリ内の依存プロキシを通じて、コンテナイメージへの読み取り専用アクセス権を付与します。
write_virtual_registryプライベートプロジェクト内の依存プロキシを通じて、コンテナイメージへの読み取り、書き込み、削除アクセス権を付与します。
read_observabilityGitLab可観測性への読み取り専用アクセス権を付与します。
write_observabilityGitLab可観測性への書き込みアクセス権を付与します。
ai_featuresGitLab Duo関連のAPIエンドポイントへのアクセス権を付与します。
sudo管理者ユーザーとして認証されている場合に、システム内の任意のユーザーとしてAPIアクションを実行する権限を許可します。
admin_mode管理者モードが有効になっている場合、管理者としてAPIアクションを実行する権限を許可します
read_service_ping管理者ユーザーとして認証された場合、API経由でService Pingペイロードをダウンロードするためのアクセス権を付与します。
openidOpenID Connectを使用してGitLabで認証する権限を許可します。また、ユーザーのプロファイルおよびグループメンバーシップへの読み取り専用アクセスも許可します。
profileOpenID Connectを使用して、ユーザーのプロファイルデータへの読み取り専用アクセスを許可します。
emailOpenID Connectを使用して、ユーザーのプライマリメールアドレスへの読み取り専用アクセスを許可します。

いつでも、取り消しを選択して、任意のアクセスを取り消すことができます。

アクセストークンの有効期限

アクセストークンの有効期限を無効にする機能は、GitLab 15.0で削除されました。アクセストークンの更新に対応するため、既存のすべてのインテグレーションを更新する必要があります。

アクセストークンは2時間後に有効期限切れになります。アクセストークンを使用するインテグレーションは、refresh_token属性を使用して新しいトークンを生成する必要があります。リフレッシュトークンは、access_token自体が有効期限切れになった後でも使用可能です。有効期限切れのアクセストークンを更新する方法については、OAuth 2.0トークンに関するドキュメントを参照してください。

この有効期限の設定は、GitLabをOAuthプロバイダーとして機能させるライブラリであるDoorkeeperのaccess_token_expires_in設定を使用して、GitLabのコードベース内で設定されています。この有効期限設定は変更できません。

アプリケーションを削除すると、そのアプリケーションに関連付けられたすべての認可とトークンも削除されます。

ハッシュ化されたOAuthアプリケーションシークレット

デフォルトでは、GitLabはOAuthアプリケーションシークレットをハッシュ化された形式でデータベースに保存します。これらのシークレットは、OAuthアプリケーションの作成直後にのみユーザーが確認できます。以前のバージョンのGitLabでは、アプリケーションシークレットをプレーンテキスト形式でデータベースに保存していました。

GitLabにおけるOAuth 2のその他の活用方法

次のことが可能です:

  • アプリケーションAPIを使用して、OAuth 2アプリケーションを作成および管理する。
  • サードパーティのOAuth 2プロバイダーを使用して、ユーザーがGitLabにサインインできるようにする。詳細については、OmniAuthのドキュメントを参照してください。
  • OAuth 2とGitLabインポーターを組み合わせることで、ユーザー認証情報をGitLab.comアカウントと共有することなく、リポジトリへのアクセスを許可する。