Skip to main content

GitHubへの認証について

認証場所に応じて異なる資格情報を使用して、 GitHubに認証することで、アカウントのリソースに安全にアクセスできます。

認証について GitHub

アカウントをセキュリティで保護するには、 GitHub上の特定のリソースにアクセスする前に認証する必要があります。 GitHubに対して認証を行う場合は、自分が正しい人物であることを証明するために、自分に固有の資格情報を指定または確認します。

GitHubでリソースにアクセスするには、ブラウザー、GitHub Desktopまたは別のデスクトップ アプリケーション、API、またはコマンド ラインを使用します。 GitHubにアクセスする各方法では、さまざまな認証モードがサポートされています。

  • 2 要素認証を使用したユーザー名とパスワード (またはソーシャル ログイン)、またはパスキー (GitHub Free、 GitHub Enterprise Cloud のみ)
  • Personal access token
  • SSH キー

ブラウザで認証する

マネージド ユーザーを含む Enterpriseのメンバーである場合は、IdP を使用してブラウザーでGitHubを認証します。 詳細については、ドキュメントの GitHub Enterprise Cloud を参照

マネージド ユーザーを含む Enterpriseのメンバーでない場合は、GitHubのユーザー名とパスワード、またはパスキーを使用して認証します。 また、2 要素認証と SAML シングル サインオンを使うこともできます。これは、組織と企業の所有者が必要とする場合があります。

メモ

2023 年 3 月より、GitHub では、GitHub.com でコードを投稿するすべてのユーザーに、1 つ以上の形式の 2 要素認証 (2FA) を有効にすることが求められます。 該当するグループに属しているユーザーは、そのグループが登録対象として選択されると通知メールを受け取り、45 日間の 2FA 登録期間が開始されて、GitHub.com での 2FA への登録を求めるバナーが表示されます。 通知を受け取らないユーザーは、2FA を有効にする必要があるグループには含まれませんが、有効にすることを強くお勧めします。

2FA 登録のロールアウトについて詳しくは、こちらのブログ記事をご覧ください。

個人アカウントやサービス アカウントなど、 GitHub.comで複数のアカウントを使用する必要がある場合は、毎回再認証する必要なく、アカウントをすばやく切り替えることができます。 詳しくは、「アカウント間の切り替え」をご覧ください。

  • ユーザー名とパスワードのみ
    • GitHubでアカウントを作成するときにパスワードを作成します。 パスワードマネージャを使用して、ランダムで一意のパスワードを生成することをお勧めします。 詳細については、 AUTOTITLE を参照してください。
    • 2FA を有効にしていない場合、 GitHub は、新しいブラウザー プロファイル、Cookie が削除されたブラウザー、新しいコンピューターなど、新しいデバイスまたは認識されないデバイスから初めてサインインするときに、追加の検証を求められる場合があります。 詳細については、 AUTOTITLE を参照してください。
  • ソーシャル ログイン
    • GitHubでアカウントを作成するときにサポートされているソーシャル ログイン プロバイダーである Google または Apple で認証を行います。 また、2FA を構成し、追加のアカウント回復メカニズムとしてパスキーまたはパスワードを追加することをお勧めします。
    • パスワードを使用して作成した既存のアカウントがある場合は、ソーシャル ログイン メールをアカウントに追加できます。 これにより、 GitHubにサインインするときに、ソーシャル ログイン ID を第 1 要素 (パスワード) の置き換えとして使用できます。
    • GitHubメール設定ページからソーシャル ログイン ID のリンクを解除できます。 詳細については、「ロックされたアカウントからメール アドレスのリンクを解除する」を参照してください。
  • 2 要素認証 (2FA) (推奨)
    • 2 要素認証 (2FA) を有効にした場合、ソーシャル ログインまたはユーザー名とパスワードでサインインした後、モバイル デバイスで時間ベースのワンタイム パスワード (TOTP) アプリケーションからコードを入力するか テキスト メッセージ (SMS) として送信するように求められます。
    • 2FA を構成した後、アカウントは 28 日間の検査期間に入ります。 その 28 日以内に 2FA を正常に実行することで、検査期間を終了できます。 その期間に 2FA を実行しない場合は、既存の GitHub セッションの 1 つ内で 2FA を実行するように求められます。
    • 2FA を実行して 28 日目の検査に合格できない場合は、2FA の設定を再構成できるショートカットが提供されます。 GitHub の残りの部分にアクセスする前に、設定を再構成する必要があります。 詳細については、 2 要素認証を使用したGitHubへのアクセス および 2 要素認証を設定する を参照してください。
    • TOTP アプリケーション またはテキスト メッセージを使用した認証に加えて必要に応じて、webAuthn を使用して GitHub Mobile または セキュリティ キーを使用して別の認証方法を追加することもできます。

GitHub Mobile を使用した 2 要素認証の構成またはセキュリティ キーを使用した 2 要素認証の構成を参照してください。

> [!NOTE]
> どの復旧方法も使用できない場合は、アカウントへのアクセスが完全に失われています。 ただし、ロックされたアカウントに関連付けられているメール アドレスのリンクを解除することはできます。 リンクを解除したメール アドレスは、その後新規または既存のアカウントにリンクできます。 詳しくは、「[AUTOTITLE](/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-your-personal-account/unlinking-your-email-address-from-a-locked-account)」をご覧ください。

  • パスキー

    • アカウントにパスキーを追加して、セキュリティで保護されたパスワードレス ログインを実現できます。 パスキーはパスワードと 2FA の両方の要件を満たすので、1 つの手順でサインインを完了できます。 「パスキーの概要」を参照してください。
  • SAML シングル サインオン

    • SAML シングル サインオンを使う組織またはエンタープライズ アカウントが所有するリソースにアクセスするには、その前に IdP による認証も必要になる場合があります。 詳細については、ドキュメントの GitHub Enterprise Cloud を参照

セッションクッキー

GitHub は、Cookie を使用してサービスを提供し、セキュリティを強化します。

GitHubの Cookie の詳細については、AUTOTITLE を参照してください。

  • gist.インスタンスの github.com および github.com ドメイン 個別の Cookie を使用します。
  • GitHub 通常は、2 週間の非アクティブ状態の後、ユーザー セッションを削除対象としてマークします。
  • GitHub では、サインアウト時にセッションがすぐに削除されることはありません。定期的に、 GitHub は期限切れのセッションを自動的に削除します。

GitHub Desktop を用いた認証

ブラウザーを使用して GitHub Desktop で認証できます。 詳しくは、「GitHub Desktop での GitHub への認証」をご覧ください。

API で認証する

さまざまな方法で API を使用して認証できます。 詳しくは、「REST API に対する認証」をご覧ください。

API に personal access token を使用して認証を行う

個人用に GitHub REST API を使用する場合は、 personal access tokenを作成できます。 可能であれば、GitHubはfine-grained personal access tokenではなくpersonal access token (classic)を使用することをお勧めします。 personal access tokenの作成の詳細については、「個人用アクセス トークンを管理する」を参照してください。

アプリを使用した API への認証

組織や他のユーザーに代わって API を使用する場合は、GitHubがGitHub Appを使用することを推奨しています。 詳しくは、「GitHub アプリでの認証について」をご覧ください。

REST API にアクセスするための OAuth app を使用して OAuth トークンを作成することもできます。 ただし、 GitHub では、代わりに GitHub App を使用することをお勧めします。 GitHub Apps を使用すると、アプリが持つアクセスとアクセス許可をより詳細に制御できます。

GitHub Actions ワークフローでの API への認証

GitHub Actions ワークフローで API を使用する場合GitHubは、トークンを作成するのではなく、組み込みのGITHUB_TOKENで認証することをお勧めします。 GITHUB_TOKEN キーを使用して、permissions へのアクセス許可を付与できます。

GITHUB_TOKEN は、ワークフローを含むリポジトリ内のリソースにのみアクセスできることに注意してください。 ワークフロー リポジトリの外部にあるリソースに変更を加える必要がある場合は、 personal access token または GitHub Appを使用する必要があります。

詳しくは、「ワークフローでの認証に GITHUB_TOKEN を使用する」をご覧ください。

コマンドラインで認証する

HTTPS と SSH の 2 つの方法でコマンド ラインから GitHub のリポジトリにアクセスでき、どちらも認証方法が異なります。 認証方法は、リポジトリのクローンを作成するときに HTTPS または SSH リモート URL を選択したかどうかに基づいて決まります。 アクセス方法の詳細については、「リモートリポジトリについて」を参照してください。

HTTPS

ファイアウォールまたはプロキシの背後にある場合でも、HTTPS 経由で GitHub 上のすべてのリポジトリを操作できます。

GitHub CLIで認証する場合は、personal access tokenで認証するか、Web ブラウザーを使用して認証できます。 GitHub CLIを使用した認証の詳細については、gh auth loginを参照してください。

GitHub CLIなしで認証する場合は、personal access tokenで認証する必要があります。 Git からパスワードの入力するダイアログが表示されたら、personal access token を入力します。 または、Git Credential Manager などの認証情報ヘルパーを使用できます。 より安全な認証方法を優先し、Git のパスワードベースの認証が削除されました。 詳しくは、「個人用アクセス トークンを管理する」をご覧ください。 Git を使用して GitHubで認証を行うたびに、資格情報ヘルパーを使用してキャッシュしない限り、 資格情報の入力を求められます

SSH

SSH 経由で GitHub 上のすべてのリポジトリを操作できますが、ファイアウォールとプロキシでは SSH 接続の許可が拒否される場合があります。

GitHub CLIで認証すると、CLI によってマシン上に SSH 公開キーが見つかると、アップロード用に SSH 公開キーを選択するように求められます。 GitHub CLIアップロード用の SSH 公開キーが見つからない場合は、新しい SSH 公開/秘密キーペアを生成し、GitHub.comのアカウントに公開キーをアップロードできます。 その後、 personal access token または Web ブラウザーを使用して認証できます。 GitHub CLIを使用した認証の詳細については、gh auth loginを参照してください。

GitHub CLIなしで認証する場合は、ローカル コンピューターで SSH 公開/秘密キーペアを生成し、GitHub.comのアカウントに公開キーを追加する必要があります。 詳しくは、「新しい SSH キーを生成して ssh-agent に追加する」をご覧ください。 Git を使用して GitHub で認証を行うたびに、キーを保存していない限り、SSH キーパスフレーズの入力 求められます。

SAML シングル サインオンの認可

personal access tokenまたは SSH キーを使用して、SAML シングル サインオンを使用する組織が所有するリソースにアクセスするには、個人用トークンまたは SSH キーも承認する必要があります。 詳細については、ドキュメントの「AUTOTITLE または GitHub Enterprise Cloud.

GitHubのトークン形式

GitHub は、トークンの種類を示すプレフィックスで始まるトークンを発行します。

メモ

2026 年 4 月 27 日から、 GitHub はステートレス形式 (ghs_APPID_JWT) の段階的なロールアウトを開始し、新しく作成されたすべての GitHub App インストール トークンに対するロールアウトが開始され、API サーフェスのパフォーマンスが向上し、信頼性が向上しました。 アプリケーションがインストール トークンの長さ 40 文字を期待または依存している場合、この新しいトークン形式が正しく処理されない可能性があります。 必要に応じてトークン形式を有効にできる一時的な要求ヘッダーを使用して、アプリとワークフローを検証できるようになりました。 一時ヘッダーの詳細については、GitHubブログを参照してください。

トークンの種類プレフィックス詳細
Personal access token (classic)ghp_
個人用アクセス トークンを管理する
Fine-grained personal access tokengithub_pat_
個人用アクセス トークンを管理する
OAuth アクセス トークンgho_
OAuth アプリの承認
あるGitHub Appのユーザーアクセス トークンghu_
ユーザーに代わってGitHub アプリで認証する
GitHub Appのインストール アクセス トークンghs_
GitHub App インストールとしての認証
GitHub App のリフレッシュトークンghr_
ユーザー アクセス トークンを更新する

GitHubトークンの種類とその管理の詳細については、GitHub 資格情報の種類のリファレンス を参照してください。