GitLabをOAuth 2.0認証のIDプロバイダとして設定します。

OAuth 2.0は、リソースオーナーに代わってクライアントアプリケーションにサーバーリソースへのアクセスをセキュアに委譲します。OAuth 2では、作成者がリソースオーナーやエンドユーザーの承認を得て、サードパーティクライアントにアクセストークンを発行することができます。

以下のタイプのOAuth 2アプリケーションをインスタンスに追加することで、GitLabをOAuth 2認証IDプロバイダとして使用することができます：

これらのメソッドは権限レベルによってのみ異なります。デフォルトのコールバック URL は SSL URLhttps://your-gitlab.example.com/users/auth/gitlab/callbackです。代わりに非 SSL URL を使用することもできますが、SSL URL を使用する必要があります。

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

  • ユーザーが GitLab.com アカウントを使ってアプリケーションにサインインできるようにします。

  • GitLabインスタンスへの認証用にGitLab.comを設定します。詳しくは、サーバーとGitLab.comのインテグレーションをご覧ください。

  • アプリケーションの作成後、外部サービスはOAuth 2 APIを使ってアクセストークンを管理することができます。

ユーザー所有のアプリケーションの作成

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

  1. 左のサイドバーで、自分のアバターを選択してください。
  2. プロフィールの編集を選択します。
  3. 左サイドバーで「アプリケーション」を選択します。
  4. 新しいアプリケーションを追加]を選択します。
  5. 名前と リダイレクト URI を入力します。
  6. 作成者のアプリケーションで定義されている OAuth 2スコープを選択します。
  7. Redirect URIには、ユーザーがGitLabで作成者を認証した後に送信されるURLを入力します。

  8. Save applicationを選択します。GitLab が提供します：

    • OAuth 2 クライアント ID をApplication IDフィールドに入力します。
    • アクセス可能な OAuth 2 クライアントシークレット：
      • GitLab 14.1 以前のシークレットフィールド。
      • GitLab 14.2以降のシークレットフィールドで コピーを選択することで。
    • GitLab 15.9以降ではRenew secret関数。このアプリケーション用に新しいシークレットを生成してコピーするには、この機能を使います。シークレットを更新すると、シークレットが更新されるまで既存のアプリケーションが機能しなくなります。

グループ所有のアプリケーションの作成

GitLab 13.11 で導入されました。

グループに新しいアプリケーションを作成するには

  1. 目的のグループに移動します。
  2. 左サイドバーで「設定」>「アプリケーション」を選択します。
  3. 名前と リダイレクト URI を入力します。
  4. 作成者のアプリケーションで定義されている OAuth 2 スコープを選択します。
  5. Redirect URIには、ユーザーがGitLabで作成者を認証した後に送信されるURLを入力します。

  6. Save applicationを選択します。GitLab が提供します：

    • OAuth 2 クライアント ID をApplication IDフィールドに入力します。
    • アクセス可能な OAuth 2 クライアントシークレット：
      • GitLab 14.1 以前のシークレットフィールド。
      • GitLab 14.2以降のシークレットフィールドで コピーを選択することで。
    • GitLab 15.9以降ではRenew secret関数。このアプリケーション用に新しいシークレットを生成してコピーするには、この機能を使います。シークレットを更新すると、シークレットが更新されるまで既存のアプリケーションが機能しなくなります。

インスタンスワイドなアプリケーションの作成

GitLab インスタンス用のアプリケーションを作成します：

  1. 左のサイドバーで、Search を選択するか、次のページに進んでください。
  2. Admin Areaを選択します。
  3. 左サイドバーで「アプリケーション」を選択します。
  4. 新規アプリケーションを選択します。

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

すべての作成者を表示

GitLab 認証情報で作成したすべてのアプリケーションを表示します：

  1. 左のサイドバーで、自分のアバターを選択してください。
  2. プロフィールの編集]を選択し、[アプリケーション]を選択します。
  3. 作成者アプリケーションのセクションを参照してください。

GitLab OAuth 2アプリケーションは、アプリケーションが異なるアクションを実行できるようにするスコープをサポートしています。利用可能なスコープについては以下の表を参照してください。

スコープ説明
apiすべてのグループとプロジェクト、コンテナレジストリ、パッケージレジストリを含む API への完全な読み取り/書き込みアクセスを許可します。
read_userユーザー名、公開電子メール、フルネームを含む、/user API エンドポイントを介した認証済みユーザーのプロファイルへの読み取り専用アクセスを許可します。また、/users 以下の読み取り専用 API エンドポイントへのアクセスも許可します。
read_apiすべてのグループ と プ ロ ジ ェ ク ト 、 コ ン テナ レ ジ ス ト リ 、 お よ びパ ッ ケージ レ ジ ス ト リ を含む API への読み取 り ア ク セ ス を許可 し ます。
read_repositoryGit-over-HTTP あるいは Repository Files API を使って非公開プロジェクトのリポジトリへの読み込み専用アクセスを許可します。
write_repositoryGit-over-HTTP を使用する非公開プロジェクトのリポジトリへの読み書きアクセスを許可します (API は使用しません)。
read_registry非公開プロジェクトのコンテナレジストリイメージへの読み取り専用アクセスを許可します。
write_registry非公開プロジェクトのコンテナレジストリイメージへの読み取り専用アクセスを許可します。
sudo管理者ユーザーとして認証された場合に、システム内の任意のユーザーとして API アクションを実行する権限を付与します。
openid OpenID Connectを使用してGitLabと認証する権限を付与します。ユーザーのプロフィールとグループメンバーシップへの読み取り専用アクセス権も付与します。
profile OpenID Connectを使用したユーザーのプロファイルデータへの読み取り専用アクセスを許可します。
email OpenID Connectを使用して、ユーザーのプライマリメールアドレスへの読み取り専用アクセスを許可します。
create_runnerRunnerの作成権限を付与します。

いつでもRevokeを選択することで、アクセスを取り消すことができます。

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

  • GitLab 14.3で導入され、オプトアウトすることができます。
  • GitLab 15.0でアクセストークンの有効期限をオプトアウトする機能が削除されました。
  • expires_in GitLab 15.10で導入された expires_inデータベース検証。expires_in GitLabインスタンスを expires_in15.10以降にアップグレードする際に、expires_in OAuthアクセストークンが expires_in設定さexpires_in れずに残っている場合 expires_in、データベースのマイグレーションでエラーが発生します。回避方法については、GitLab 15.10.0アップグレードドキュメントをご覧ください。
caution
アクセストークンの有効期限をオプトアウトする機能はGitLab 14.3で廃止され、15.0で削除されました。すべての既存のインテグレーションは、アクセストークンの更新をサポートするように更新する必要があります。

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

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

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

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

フラグ: セルフマネジメントのGitLabでは、デフォルトでこの機能が利用可能です。この機能を隠すには、管理者がhash_oauth_secrets という機能フラグを無効にします。GitLab.comでは、この機能は利用可能です。

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

GitLabでOAuth 2を使う他の方法

以下のようなことができます：

  • Applications API を使用して OAuth 2 アプリケーションを作成および管理します。
  • サードパーティのOAuth 2プロバイダを使って、ユーザーがGitLabにサインインできるようにします。詳しくはOmniAuth のドキュメントをご覧ください。
  • GitLab Importer with OAuth 2を使って、GitLab.comアカウントのユーザー認証情報を共有せずにリポジトリにアクセスできるようにします。