GitHub の認証について
アカウントを安全に保つには、GitHub Enterprise Cloud の特定のリソースにアクセスする前に認証する必要があります。 GitHub Enterprise Cloud への認証を行うときは、自分が確かに本人であることを証明するために、固有の認証情報を提供または確認します。
GitHub Enterprise Cloud のリソースには、ブラウザ内、GitHub Desktop または別のデスクトップアプリケーション経由、API 経由、またはコマンドライン経由など、さまざまな方法でアクセスできます。 GitHub Enterprise Cloud へのアクセス方法は、それぞれ異なる認証モードをサポートしています。
- ID プロバイダー (IdP)
- 2 要素認証を使用したユーザー名とパスワード、またはパスキー
- Personal access token
- SSH キー
ブラウザで認証する
マネージド ユーザーを含む Enterprise のメンバーである場合は、IdP を使ってブラウザーで GitHub Enterprise Cloud に対して認証します。 詳しくは、GitHub Enterprise Cloud ドキュメントの「Enterprise Managed Users について
マネージド ユーザーを含む Enterprise のメンバーでない場合は、GitHub のユーザー名とパスワード 、またはパスキー を使用して認証します。 また、2 要素認証と SAML シングル サインオンを使うこともできます。これは、組織と企業の所有者が必要とする場合があります。
注: 2023 年 3 月より、GitHub では、GitHub.com でコードを投稿するすべてのユーザーに、1 つ以上の形式の 2 要素認証 (2FA) を有効にすることが求められます。 該当するグループに属しているユーザーは、そのグループが登録対象として選択されると通知メールを受け取り、45 日間の 2FA 登録期間が開始されて、GitHub.com での 2FA への登録を求めるバナーが表示されます。 通知を受け取らないユーザーは、2FA を有効にする必要があるグループには含まれませんが、有効にすることを強くお勧めします。
2FA 登録のロールアウトについて詳しくは、こちらのブログ記事をご覧ください。
個人用アカウントやサービス アカウントなど、GitHub.com で複数のアカウントを使用する必要がある場合は、毎回再認証する必要なく、アカウントをすばやく切り替えることができます。 詳しくは、「アカウント間の切り替え」を参照してください。
-
ユーザー名とパスワードのみ
- GitHub Enterprise Cloud でアカウントを作成するときにパスワードを作成します。 パスワードマネージャを使用して、ランダムで一意のパスワードを生成することをお勧めします。 詳細については、「強力なパスワードの作成」を参照してください。
- 2FA を有効にしていない場合、GitHub Enterprise Cloud では、新規または、認識できないデバイス (新しいブラウザー プロファイル、Cookie が削除されたブラウザー、新しいコンピューターなど) から初めてサインインしたときに、追加の検証を求められます。 詳しくは、「サインイン時の新しいデバイスを確認」をご覧ください。
-
2 要素認証 (2FA) (推奨)
-
2FA を有効にした場合は、ユーザー名とパスワードを正常に入力した後、モバイル デバイスで時間ベースのワンタイム パスワード (TOTP) アプリケーションによって生成されるか、テキスト メッセージ (SMS) として送信されるコードも指定するように求められます。
-
2FA を構成した後、アカウントは 28 日間の検査期間に入ります。 その 28 日以内に 2FA を正常に実行することで、検査期間を終了できます。 その期間内に 2FA を実行しない場合は、既存の GitHub セッションのいずれかで 2FA を実行するように求められます。
-
2FA を実行して 28 日目の検査に合格できない場合は、2FA の設定を再構成できるショートカットが提供されます。 GitHub の残りの部分にアクセスするためには、設定を再構成する必要があります。 詳しくは、「2 要素認証を利用した GitHub へのアクセス」と「2 要素認証を設定する」をご覧ください。
-
TOTP アプリケーションまたはテキスト メッセージを使った認証に加えて、必要に応じて代替の方法として、GitHub Mobile での認証か、WebAuthn を使ったセキュリティ キーを追加できます。 詳しくは、「2 要素認証を設定する」と「2 要素認証を設定する」をご覧ください。
注: どの復旧方法も使用できない場合は、アカウントへのアクセスが完全に失われています。 ただし、ロックされたアカウントに関連付けられているメール アドレスのリンクを解除することはできます。 リンクを解除したメール アドレスは、その後新規または既存のアカウントにリンクできます。 詳しくは、「ロックされたアカウントからメール アドレスのリンクを解除する」を参照してください。
-
-
パスキー
- アカウントにパスキーを追加して、セキュリティで保護されたパスワードレス ログインを実現できます。 パスキーはパスワードと 2FA の両方の要件を満たすので、1 つの手順でサインインを完了できます。 「パスキーの概要」を参照してください。
-
SAML シングル サインオン
- SAML シングル サインオンを使う組織またはエンタープライズ アカウントが所有するリソースにアクセスするには、その前に IdP による認証も必要になる場合があります。 詳しくは、「SAMLのシングルサインオンでの認証について」をご覧ください。
セッション Cookie
GitHub は、Cookie を使用してサービスとセキュリティで保護された GitHub.com を提供します。 GitHub の Cookie に関する詳細は、プライバシー/Cookie リポジトリで確認できます。
- gist.github.comとインスタンスのgithub.com ドメインでは個別の Cookie を使用します。
- GitHub Enterprise Cloud は、通常、非アクティブ状態が 2 週間後にユーザー セッションに削除のマークを付けます。
- GitHub Enterprise Cloud は、サインアウト時にセッションを直ちに削除しません。GitHub Enterprise Cloud は定期的に、期限切れのセッションを自動的に削除します。
GitHub Desktop で認証する
お使いのブラウザを使用して GitHub Desktop で認証できます。 詳しくは、「GitHub Desktop での GitHub への認証」を参照してください。
API で認証する
さまざまな方法で API を使用して認証できます。 詳しくは、「REST API に対する認証」を参照してください。
personal access token で API に認証を行う
個人用に GitHub REST API を使用する場合は、personal access tokenを作成できます。 可能であれば、GitHub は、personal access token (classic) ではなく fine-grained personal access token を使うことをお勧めします。 personal access tokenの作成について詳しくは、「個人用アクセス トークンを管理する」をご覧ください。
アプリを使用した API への認証
Organization または他のユーザーの代わりに API を使用する場合、GitHub では、GitHub App の使用が推奨されます。 詳しくは、「GitHub アプリでの認証について」を参照してください。
また、OAuth app を使用して OAuth トークンを作成し、REST API にアクセスすることもできます。 しかし、GitHub では、代わりに GitHub App を使用することが推奨されます。 GitHub Apps を使うと、アプリのアクセスとアクセス許可をより詳細に制御できます。
GitHub Actions ワークフローにおける API への認証
GitHub Actions ワークフローで API を使用する場合、GitHub では、トークンを作成するのではなく、組み込み GITHUB_TOKEN
で認証することが推奨されます。 permissions
キーを使用して、GITHUB_TOKEN
へのアクセス許可を付与できます。
GITHUB_TOKEN
は、ワークフローを含むリポジトリ内のリソースにのみアクセスできることに注意してください。 ワークフロー リポジトリの外部にあるリソースを変更する必要がある場合は、personal access token または GitHub App を使う必要があります。
詳しくは、「自動トークン認証」を参照してください。
コマンドラインで認証する
コマンドラインから GitHub Enterprise Cloud のリポジトリにアクセスするには、HTTPS と SSH の 2 つの方法がありますが、それぞれ認証方法が異なります。 認証方法は、リポジトリのクローンを作成するときに HTTPS または SSH リモート URL を選択したかどうかに基づいて決まります。 アクセス方法について詳しくは、「リモートリポジトリについて」をご覧ください。
HTTPS
ファイアウォールまたはプロキシの内側からでも、HTTPS を介して GitHub Enterprise Cloud 上のすべてのリポジトリを操作できます。
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 Enterprise Cloud で認証するたびに、資格情報ヘルパーでキャッシュしない限り、GitHub Enterprise Cloud で認証するための資格情報を入力するように求められます。
SSH
SSH 接続はファイアウォールとプロキシから許可されない場合がありますが、SSH 経由で GitHub Enterprise Cloud 上のすべてのリポジトリを操作できます。
GitHub CLI で認証すると、CLI によってマシン上で 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 Enterprise Cloud で認証するたびに、キーを保存していない限り、SSH キー パスフレーズを入力するように求められます。
SAML シングル サインオンの認可
personal access token または SSH キーを使って、SAML シングル サインオンを使う組織が所有するリソースにアクセスするには、個人用トークンまたは SSH キーも認可する必要があります。 詳しくは、「SAMLシングルサインオンで利用するために個人アクセストークンを認可する」または「SAMLシングルサインオンで利用するためにSSHキーを認可する」をご覧ください。
GitHub のトークンフォーマット
GitHub は、トークンの種別を示すプレフィックスで始まるトークンを発行します。
トークンの種類 | Prefix | 詳細情報 |
---|---|---|
Personal access token (classic) | ghp_ | 「個人用アクセス トークンを管理する」 |
Fine-grained personal access token | github_pat_ | 「個人用アクセス トークンを管理する」 |
OAuth アクセス トークン | gho_ | 「OAuth アプリの承認」 |
GitHub App のユーザー アクセス トークン | ghu_ | ユーザーに代わって GitHub アプリで認証する |
GitHub App インストール アクセス トークン | ghs_ | 「GitHub App インストールとしての認証」 |
GitHub App のトークンのリフレッシュ | ghr_ | ユーザー アクセス トークンを更新する |