# GitHub アプリ vs. OAuth アプリ：最適な GitHub 連携方法を選ぼう
Logto 統合のための GitHub アプリと OAuth アプリを比較します。セキュリティ、権限、トークン管理の主な違いを学び、アプリケーションに最適な GitHub 認証方法を選択しましょう。
Product & Design
Logto アプリケーションに GitHub 認証を導入する際、選べるのは GitHub アプリか GitHub OAuth アプリの 2 種類です。どちらも「GitHub でサインイン」機能を実現しますが、セキュリティやトークン管理、API アクセスにおいて根本的に異なる体験を提供します。このガイドでは、その重要な違いを理解し、ユースケースに最適な方法を選ぶ手助けをします。
背景：2つの GitHub 連携ルート
Logto の現行ドキュメントでは、GitHub OAuth アプリ の設定方法を説明しています。これは最もシンプルで分かりやすく、基本的な認証ニーズに最適な選択肢です。一方で、GitHub アプリは GitHub 自体が推奨する最新の方式であり、より強化されたセキュリティ機能や細かなコントロールが可能です。
例えるなら、OAuth アプリは家のマスターキーを誰かに渡すようなもの—一度許可すると広範囲にアクセスされます。一方 GitHub アプリは、部屋ごとのアクセスコードがあるスマートロックのようなもの—アプリに必要な権限だけを正確に付与できます。
主な違いの早見表
権限：広範 vs. 細分化
- OAuth アプリ は広いスコープを利用します。
repoをリクエストすると、リポジトリ全体へのフルコントロール権限を取得します。 - GitHub アプリ は細かく制御された権限を使います。例えば「Issues: 読み取り」だけをリクエストでき、コードへは触れません。インストール時にユーザーは特定のリポジトリを選択でき、すべて一括で許可する必要はありません。
トークン・セキュリティ：永続 vs. 期限あり
- OAuth アプリ のトークンは失効しません（手動で取り消さない限り）。リフレッシュ機構もありません。
- GitHub アプリ のトークンは有効期限が短く（1時間）、自動リフレッシュに対応。長時間稼働するアプリでも非常に安全です。
アイデンティティ：ユーザー vs. ボット
- OAuth アプリ は常に認可ユーザー（例:
@octocat）として動作し、そのユーザーのレート制限（5,000 回/時）を共有します。 - GitHub アプリ は独立したボットとして動作でき（例:
@my-app[bot]）、利用に応じてレート制限もスケーラブルに増加し、自動化に最適です。
アクセス制御：一括 vs. 選択的
- OAuth アプリ は一度の許可で利用可能なリソース全てにアクセス権が付与されます。
- GitHub アプリ はインストール時にユーザーが特定のリポジトリだけ選択でき、権限の変更があった場合も webhook 通知が届くため、透明性とコントロール性が向上します。
永続性 ：ユーザー依存 vs. 独立
- OAuth アプリ は認可したユーザーに紐づきます。その開発者がアクセスを失うか組織から退会するとアプリは使えなくなります。
- GitHub アプリ はインストールした開発者が組織から抜けても引き続き動作し、自動化や統合サービスの継続を保証します。
どちらを選ぶべき？
GitHub アプリと OAuth アプリのどちらも Logto のソーシャルコネクターとシームレスに連携可能です。Secret Vault にはいずれの方式のトークンも安全に保管されますが、それぞれ体験は大きく異なります：
OAuth アプリによる基本的なソーシャルサインイン
もしユーザー認証（GitHub でサインイン）のみが必要で、その後 GitHub API を利用しない場合は、OAuth アプリの導入が最も手軽です：
- セットアップが簡単：ユーザーが OAuth アプリの認可に同意し、GitHub でサインインします。
- トークンは長寿命（リフレッシュ不要）：Logto は Secret Vault にアクセストークンを保存しますが、リフレッシュフローはありません—トークンは取り消されるまで有効です。
- ユーザーの識別情報（メール、名前、アバター）だけが必要で、自動 API 処理を行わない場合に最適です。
この方法を選ぶ理由：試作品やログイン・たまのプロフィール同期だけが必要なアプリに最速で実装可能です。
GitHub アプリによる高度な統合
GitHub API への継続的なアクセスやバックグラウンド自動化、より厳格なセキュリティが必要な場合は、GitHub アプリがベストです：
- 細分化された権限やリポジトリ単位の選択で、最小限かつ監査可能なア クセスを維持します。
- トークンは短命（通常 1 時間）ですが、GitHub アプリではリフレッシュトークンも取得可能。Logto でアクセストークンとリフレッシュトークンの両方を Secret Vault に保存、ローテーションも自動で管理し、再ログイン不要でバックエンドの動作が継続します。
- ボットとしてのアプリ・アイデンティティで操作内容の帰属が明確になり、大量自動化にも強いスケーラブルなレート制限。
適した用途：
- ユーザーの代わりに GitHub リポジトリを管理する SaaS プラットフォーム
- コードやイシュー、プルリクエストとやりとりする AI エージェント
- 継続的な API アクセスが必要なアプリ
- バックグラウンド自動化タスクを行うツール
Logto で GitHub アプリをセットアップする
GitHub アプリのセットアップは OAuth アプリとほぼ同じ流れですが、いくつかの重要な違いがあります。OAuth アプリから GitHub アプリへの移行も最小限の作業で済みます。
GitHub アプリの作成手順
-
「GitHub の設定 > Developer settings > GitHub Apps」へアクセス
-
「New GitHub App」をクリック
-
以下を設定：
- GitHub アプリ名: アプリのユニークな識別名
- ホームページ URL: アプリのウェブサイト
- コールバック URL: Logto コネクターのコールバック URI（OAuth アプリと同じ）
- インストール時にユーザー認可（OAuth）をリクエスト: 有効化
- Webhook: 必要に応じて設定
- 権限: 細かい権限（例: 「Issues: 読み取り」）を選択
- ユーザー権限: ユーザーの代行動作が必要な場合は追加
-
クライアントシークレットを発行（OAuth アプリと同様）
Logto への設定方法
Logto 側でのコネクター設定もほとんど同じです：
- GitHub アプリの Client ID を入力
- Client secret を入力
- GitHub API コールが必要な場合は 「トークン保存による持続的 API アクセス」 を有効化
- 重要な違い—スコープについて：
- OAuth アプリでは Logto の scope フィールドにスコープを追加する必要がありますが、GitHub アプリの権限は GitHub のアプリ設定で選択します。
- そのため Logto の scope フィールドは空のままにしておきます
- リフレッシュトークン取得（オプション）
- Logto の scope フィールドに
offline_accessを追加するとリフレ ッシュトークンが有効になります - GitHub で自動的にリフレッシュトークンが発行され、Logto 側でローテーション・保存が自動管理されます
- 注意：OAuth アプリはリフレッシュトークン非対応で、アクセストークンは失効しません。したがって
offline_accessは OAuth アプリには適用されません。これは GitHub アプリ統合時と大きく異なります。
- Logto の scope フィールドに
まとめ
基本的な認証なら OAuth アプリも妥当な選択肢ですが、GitHub アプリこそが今後の GitHub 連携の主流です。トークン有効期限による堅牢なセキュリティ、より細やかな権限管理、ユーザーによるアクセス制御の容易さなど、圧倒的なメリットがあります。
Logto ユーザーならどちらもソーシャルコネクターで利用できます。最終的な選択肢はニーズ次第です：
- 認証だけなら OAuth アプリでシンプルに開始
- API アクセスや自動化、高度なセキュリティが必要なら GitHub アプリへステップアップ
そして、Logto の Secret Vault と自動トークンリフレッシュ機能のおかげで、GitHub アプリのトークンも OAuth アプリ同様に手軽に管理できます。AI コーディングアシスタント、プロジェクト管理プラットフォーム、開発者向け生産性ツールなど…どんな用途でも、Logto アプリに最適な GitHub 連携方法を選べる知識が身につきました。
始める準備はいいですか？さっそく Logto の GitHub コネクター をチェックして、GitHub 認証統合を始めましょう！