GitHub SSOの設定とログイン｜SAML連携とPAT・SSH・gh CLIの認可【2026年10月】

GitHub SSOは、Microsoft Entra IDやOktaなどのIdP（Identity Provider）での認証を、Organizationのリソースへアクセスする条件にする仕組みです。この記事で扱うのはGitHub.comのOrganization向けSSOで、使えるのはGitHub Enterprise Cloudだけです。FreeとTeamには設定項目がありません（GitHub Enterprise ServerにもSAML SSOはありますが、設定方法が別です）。導入でつまずくのは設定画面よりも、その後のコマンドラインです。ブラウザではSSOでログインできているのに、git pushやAPI、GitHub CLI（gh）だけが403や404で失敗する。よくある原因が、パーソナルアクセストークン（PAT）とSSHキーの「SSO認可」漏れです（トークンの権限不足やリポジトリのアクセス権不足でも同じ症状になるので、切り分けは後述します）。使える条件と設定手順、SSOログインの導線とセッション、PAT・SSHキー・gh CLIの認可とエラーの直し方を、GitHub公式ドキュメントの記述にそって整理します。

まとめ

• SAML SSOはGitHub Enterprise Cloud限定。Teamでは使えない。価格はTeamが$4、Enterpriseが$21（1ユーザー・月額、最初の12か月の表示価格）。
• 管理者がGitHubに入れるのはSign on URL・Issuer・公開証明書の3つ。「Test SAML configuration」が成功しないと保存できない。
• ユーザーのSSOログインURLは https://github.com/orgs/組織名/sso。SSOセッションはIdPが指定しない限り24時間（Entra IDでは変更できない）。
• 一度SSOでログインした人は、強制（enforce）前でも、認可済みのPATとSSHキーしかそのOrganizationで使えない。classic PATとSSHキーは「Configure SSO」から認可し、fine-grained PATは作成時に認可される。
• classic PATのSSO認可不足で403が返る場合は、応答ヘッダー X-GitHub-SSO に認可用URLが入る（1時間で失効）。gh CLIは「Authorize in your web browser:」としてそのURLを表示する。
• 強制すると、そのOrganizationでIdP認証を済ませて外部IDをひも付けていないメンバーと、外部IDのないボット・サービスアカウントはOrganizationから外れる。CIはGitHub Appのインストールアクセストークンへ寄せると、個別のSSO認可が要らない。

GitHub SSOを使える条件（プラン・IdP・方式）

Organization向けSAML SSOの対応プラン

公式ドキュメントの各ページには「SAML SSOを使うには、OrganizationがGitHub Enterprise Cloudを使っている必要がある」という注記が付いています（About identity and access management with SAML single sign-on）。GitHubのPricingページ（2026年10月14日確認）でも、SAML single sign-onとSCIMによるユーザープロビジョニングはEnterpriseの機能です。価格はTeamが$4、Enterpriseが$21からで、どちらも「最初の12か月」の表示です。Teamのまま追加費用でSSOだけ付ける選択肢はなく、SSOを入れる判断はEnterpriseへ上げる判断と同じです。Enterprise Cloudの無料トライアルで、本番に触れずにIdP連携を試せます。

公式にテスト済みのIdPとSCIM対応のIdP

GitHubはSAML 2.0を実装したIdPならつながるとしたうえで、自社でテストしている6つのIdPを挙げています。SCIM（IdP側の付与・剥奪に合わせてメンバーを自動で増減させる仕組み）に対応するIdPはさらに絞られ、Organization向けは3つだけです（About SCIM for organizations）。

Google WorkspaceやKeycloakもSAML 2.0のIdPとして接続できますが、GitHubのテスト対象外です。入退社に合わせた自動削除まで求めるなら、SCIM対応の3つから選ぶのが近道です。IdPをこれから選ぶならKeycloakとは？Oktaとの違いと連携手順、SAMLの仕組みそのものはSAMLとは？認証フロー・IdP/SPの仕組みを参照してください。

SAMLとOIDCの選び方（Enterprise Managed Users）

通常のSSOはSAMLだけです。OIDCを選べるのは、企業がアカウントそのものを発行・所有するEnterprise Managed Users（EMU）で、IdPがEntra IDの場合に限られます（Configuring OIDC for Enterprise Managed Users）。OIDCにすると、Entra IDの条件付きアクセスポリシー（CAP）のIP条件が、PATやユーザーSSHキーによる認証のたびに評価されます。Webセッションへの適用はパブリックプレビューで、「Authentication security」で別途有効にします。制約は、1つのEntra IDテナントにOIDC連携は1つのenterpriseまで、IdP起点のログイン不可、カスタムクレーム不可の3点。セッションの長さはIDトークンの寿命で決まり、既定は1時間です。EMUをSAMLで使う場合にGitHubがパートナーIdPとして扱うのは、Entra ID・Okta・PingFederateの3つです。2026年9月24日には、Entra IDをIdPとするEMUで、トークンの作成やWebhookの編集といった影響の大きい操作の前にIdPでの再認証を求める「Proof of Presence」がパブリックプレビューとして追加されました（GitHub Changelog）。

選び方の目安は次のとおりです。EMUとEntra IDを使い、同一テナントから接続するenterpriseが1つで、IdP起点ログインやカスタムクレームが不要ならOIDCを推奨します。それらが必要ならSAMLを選びます。プロトコルの優劣ではなく、構成で決まります。OIDCのIDトークン検証の中身はOIDC（OpenID Connect）とは？IDトークンの検証手順で解説しています。

SAML SSOの設定単位とSCIMへの影響

SAML SSOはOrganizationごとにも、enterpriseアカウントでまとめても設定できます。enterprise側で必須にすると、Organization単位の設定は上書きされ、配下の全Organizationで強制されます。複数のOrganizationをenterprise単位でまとめるとSAML設定を集約できます。ただし、個人アカウントを使うOrganization向けSCIMはenterprise単位のSSOでは利用できないため、自動プロビジョニングの要件も合わせて選びます。EMUはenterprise単位で設定します。なお、IdPのダッシュボードから招待なしでOrganizationに参加させるURL（https://github.com/orgs/組織名/sso/sign_up）は、Organization単位で設定したときだけ使えます。

SAML SSOを設定する手順（管理者）

GitHubとIdPに入れる値

Organizationの「Settings」→「Authentication security」→「Enable SAML authentication」を開くと、入力欄は3つです。逆向きに、GitHub側のURLをIdPのアプリ設定へ登録します。Entra IDのギャラリーアプリ「GitHub Enterprise Cloud – Organization」の場合、Microsoftのチュートリアルに示されている値は次のとおりです。

Issuerは任意項目ですが、IdPのグループとGitHubのTeamを同期するチーム同期（team synchronization）を使うなら必須です。後から足そうとして詰まりやすいので、最初から入れておきます。Entra IDでのギャラリーアプリの追加は、Entra管理センターに少なくともクラウドアプリケーション管理者としてサインインして行います。NameIDの形式やメタデータの不一致でログインが失敗する場合の切り分けは、SAML NameIDFormatとメタデータの不一致でSSOが失敗する原因の切り分けにまとめました。

有効化・テスト・強制の順序

OrganizationのSAML SSOには「無効」「有効だが強制しない」「有効かつ強制」の3つの状態があります（Enabling and testing SAML single sign-on for your organization）。進め方は次の順です。

1. 3つの値を入れ、署名方式とダイジェスト方式をIdPに合わせる。
2. 「Test SAML configuration」を押す。SP起点の認証で試すテストで、成功しないとSAML設定を保存できない。
3. 「Require SAML SSO authentication for all members」は外したまま保存する。未認証のメンバーは削除されないが、SSOで外部IDをひも付けたメンバーは、強制前でもPAT・SSHキーの認可が必要になる。
4. リカバリーコードをダウンロードし、パスワードマネージャーなどに保管する。IdPが止まったときに管理者が入る唯一の手段になる。
5. メンバーがIdP経由でログインし、外部IDのひも付け（linked identity）ができるのを待つ。
6. 強制をオンにする。未認証のメンバーが一覧表示されるので、確認して「Remove members and require SAML single sign-on」を押す。

強制でOrganizationから外れたメンバーには通知メールが届きます。SAML SSOで認証すれば戻れ、3か月以内なら権限と設定も復元されます（Enforcing SAML single sign-on for your organization）。外部コラボレーター（outside collaborator）はSSO認証の対象外です。IdPでの退職処理が届かないので、別に棚卸しが要ります。

IdPの証明書を更新するときのdigest mismatch

GitHubは、登録したIdP証明書の有効期限を見ていません。期限が切れてもSAML認証は通り続けます。危ないのは逆の操作で、IdP側で証明書を作り直したのにGitHubの「Public Certificate」を差し替えないと、全員のログインが digest mismatch エラーで失敗します。証明書の更新はIdPとGitHubを同じ作業枠で行い、更新前にリカバリーコードの所在を確かめておきます。

ユーザー向けSSOのログインURLとセッション管理

SSOのログインURL

SSOを有効にしたOrganizationのリソースを開くと、IdPへリダイレクトされます。ブラウザで直前にIdPへログインしていれば、そのまま通ります。SSOのセッションを明示的に作りたいとき（OAuthアプリやgh CLIを認可する前など）は、次のURLを開きます。

https://github.com/orgs/ORGANIZATION-NAME/sso
https://github.com/enterprises/ENTERPRISE-NAME/sso

EMUでない通常の構成では、メンバーは自分の個人アカウントでサインインし、そこにIdPの外部IDがひも付きます。SSOはGitHubのログインを置き換えません。EMUでは企業が発行した専用アカウントでサインインします。

セッションは24時間・確認と失効の場所

SSOセッションの長さは、IdPが別に指定しない限り24時間です（About authentication with single sign-on）。翌朝にもう一度IdPの認証を求められるのは仕様です。GitHub側のSAMLセッション時間を変更するには、IdPがSAML応答のSessionNotOnOrAfter属性を設定できる必要があります。Entra IDはこの属性に対応しておらず、SAMLトークンの有効期間ポリシーを変更してもGitHubのセッション時間は変わりません。

自分のセッションは「Settings」→「Access」の「Sessions」→「Web sessions」で確認でき、「See more」から「Revoke session」で取り消せます。取り消すとそのOrganizationへのSSO認証が消え、次はIdP経由でのログインが必要です。GitHubはSAMLのシングルログアウトに対応していないため、GitHubからログアウトしてもIdPのセッションは残ります。共用端末ではIdP側でもログアウトしてください。

「この外部IDは別のアカウントにひも付いている」と出たとき

1つのOrganizationの中で、GitHubアカウントと外部IDは1対1でひも付きます。新しいGitHubアカウントで同じIdPアカウントを使ってSSOすると、ひも付き済みのエラーで止まり、本人側では直せません。管理者に旧アカウントとのひも付きを解除してもらいます。逆に、ひも付きと違う外部IDでログインすると「再リンクする」警告が出ます。続けるとチームへのアクセスを失うことがあるので、意図しない警告なら進めないでください。

PAT・SSHキー・gh CLIのSSO認可とエラー対処

PAT・SSHキーの認可が必要になる時点

APIやコマンドラインのgitでSSO保護下のリソースに触るには、そのOrganization向けに認可したPAT（HTTPS）かSSHキーが要ります。見落とされやすいのは時点です。公式ドキュメントは、そのOrganizationで一度でもSSOログインして外部IDがひも付いた人は、SSOが強制されていなくても、認可済みのPATとSSHキーしか使えないと注記しています（Authorizing a personal access token for use with single sign-on）。「まだ強制していないから大丈夫」と考えていると、SSOを試した開発者から順にpushが通らなくなります。有効化の告知と同時に、認可の手順も配るのが安全です。

classic PATとfine-grained PATの違い

classic PATは、トークン一覧で対象トークンの「Configure SSO」を開き、Organizationの右にある「Authorize」を押します。「Configure SSO」が表示されないのは、まだ一度もそのOrganizationでIdP認証をしていないからです。先に前述のSSOログインURLを開いて外部IDをひも付けてから、一覧に戻ります。enterpriseでIP許可リストとSSOを両方有効にしている場合は、認可の操作をするIPもenterpriseの許可リストに入っている必要があります。PATの作成手順やclassicとfine-grainedの選び分けはGitHub PAT（Personal Access Token）とは？で詳しく解説しています。

SSHキーの認可

SSHキーも「Settings」→「SSH and GPG keys」で、キーの右の「Configure SSO」から認可します（Authorizing an SSH key for use with single sign-on）。Organizationの認証局（SSH CA）が署名したSSH証明書は認可が要りません。デプロイ用の鍵が多い組織では、SSH CAを使うと鍵ごとの認可作業そのものがなくなります。

PAT・SSHキーのSSO認可が失効する条件

認可は取り消されるまで有効ですが、次のいずれかで外れます。以前は成功していたCIが認証エラーになる場合は、認可の取り消しやトークンの変更・期限切れを確認します。

• OrganizationやenterpriseのオーナーがAuthorizationを取り消した（個人単位・全員・認証情報の種類単位で取り消せる）
• 本人がOrganizationから外れた
• PATのスコープを編集した、またはトークンを再生成した
• PATが作成時に決めた有効期限を迎えた

特に注意したいのはSSHキーです。Organizationが認可を取り消したSSHキーは、同じ鍵を再認可できません。新しい鍵を作って登録し直すことになります。PATを再生成したら、CIのシークレットを差し替えるのと同時に、もう一度「Configure SSO」から認可してください。

Organizationが多いenterpriseでは、この手作業を自動化できるようになりました。2026年9月16日から、enterprise単位のSSOを使うEnterprise Cloudでは、enterpriseにインストールしたGitHub App（enterprise_credentials:write 権限）がAPIを呼び、既存のclassic PATやSSHキーを1回のリクエストで最大50のOrganizationへ一括認可できます（GitHub Changelog）。enterprise設定でのオプトインが必要で、認証情報はトークンIDやSSHキーのフィンガープリントで指定するため、秘密そのものはGitHub Appに渡りません。トークンをローテーションするたびにこのAPIを呼ぶ運用にすれば、サービスアカウントの認可漏れを防げます。

403・404の見え方とgh CLIでの直し方

未認可のclassic PATで1つのOrganizationにアクセスすると、APIは 404 Not Found か 403 Forbidden を返します（Authenticating to the REST API）。404は「リポジトリが存在しない」と区別がつかないので、まず認可を疑います。403のときは応答ヘッダー X-GitHub-SSO に認可用のURLが入り、そのURLは1時間で失効します。複数のOrganizationをまたぐ呼び出しでは、SSOが必要なOrganizationの結果だけが抜け、ヘッダーにそのOrganizationのIDが並びます。

# 応答ヘッダーを見る（TOKEN と ORG は置き換える）
curl -s -o /dev/null -D - \
  -H "Authorization: Bearer $TOKEN" \
  https://api.github.com/orgs/ORG/repos | grep -i x-github-sso

# 1つのOrganizationで未認可のとき（形式）
X-GitHub-SSO: required; url=<認可用URL>

# 複数Organizationで一部が未認可のとき（公式ドキュメントの例）
X-GitHub-SSO: partial-results; organizations=21955855,20582480

GitHub CLIはこのヘッダーを読みます。cli/cliのソース（v2.102.0、2026年9月30日リリース時点）では、APIエラーの応答に X-GitHub-SSO のURLがあると、エラーメッセージに続けて次の1行を表示します。

Authorize in your web browser:  https://github.com/...

表示されたURLをブラウザで開いて認可すれば、同じコマンドが通ります。gh CLIはOAuthアプリとして認可されるので、ログインし直す場合も順番が大事です。先にSSOログインURLでセッションを作り、そのあと gh auth login --web（既存のログインなら gh auth refresh）でブラウザの認可をやり直します。環境変数 GH_TOKEN にPATを入れて使っている場合は、そのPAT自体の認可が要ります。ghの認証まわりの操作全般はghコマンド（GitHub CLI）とは？を参照してください。

gh auth status          # どのアカウント・どのトークンで動いているか
gh auth refresh -h github.com   # SSOセッションを作った後にブラウザで再認可

OAuthアプリとGitHub Appの再認可

OAuthアプリやGitHub AppをSSOのOrganizationで使うには、そのアプリを認可する時点でSSOセッションが有効である必要があります。セッションがない状態で認可すると、アプリはそのOrganizationにアクセスできません。さらに、SSOを有効化・強制したあとで初めてSSOログインした人は、以前に認可したOAuthアプリとGitHub Appを認可し直す必要があります。自分が認可したアプリは https://github.com/settings/applications（OAuthアプリ）と https://github.com/settings/apps/authorizations（GitHub App）で確認できます。

CIとボットを止めない設計

強制前には、人のログインに加えて、CI・ボット・外部サービスの認証も確認します。確認するものは2つです。1つ目はボットとサービスアカウントの削除です。IdPに外部IDを持たないボットやサービスアカウントは、強制の時点でOrganizationから外されます（Managing bots and service accounts with SAML single sign-on）。強制するなら、マシンユーザーにもIdPのアカウントを作って一度SSOログインさせ、そのPATとSSHキーを認可しておきます。

2つ目は外部サービスのOAuth連携です。GLOBIS社がZennで公開したGitHub SSO導入の記録では、SSOの有効化でCircleCI・ZenHub・GitHub Mobile・AWS CodeBuildなどのOAuth連携がアクセスを失い、混乱が起きたと書かれています。CircleCIについては、プロジェクトのフォロー解除やデプロイキーの削除が起こることがあり、再設定が必要だと説明されています。強制の前に、OrganizationのOAuthアプリとGitHub Appの一覧を出し、再認可の担当者と手順を決めておきます。

結論として、CIの認証はPATではなく、GitHub Appのインストールアクセストークンへ寄せるべきです。ユーザーアクセストークンと違って個人のアクセス権に依存せず、個別のSSO認可も要りません。ただしトークンは1時間で失効するため、ジョブの実行時に発行する仕組みが必要です。ワークフローを実行するリポジトリ内の処理なら、組み込みの GITHUB_TOKEN を最小権限で使う設計が先に来ます（GitHub Actionsのpermissions｜GITHUB_TOKENの既定権限と最小権限の設計）。必須ステータスチェックでCIをブランチ保護に組み込んでいる場合、認証の切れたワークフローはそのままマージを止める点にも注意してください。

SCIM未導入時の退職者削除とトークン失効

SAML SSOが統制するのはログインの入口だけです。公式ドキュメントによると、SCIMなしの運用では、IdPでアクセスを外してもセッション切れの時点でOrganizationから自動では外れません。そして認可済みのトークンは、セッションが切れた後もOrganizationにアクセスできます。IdPでアカウントを止めただけでは、退職者のPATが生きている可能性があります。

SCIMを使わないなら、退職処理に「IdPで無効化」と「GitHubのOrganizationから削除」の両方を入れます。SCIMを使う場合は、SCIM用のOAuthアプリを認可したユーザーが組織を離れるとSCIMが止まるため、専用のユーザー（Organizationオーナー・ライセンスを1つ消費）を用意するよう公式が推奨しています。IdPのNameIDとSCIMのuserNameも一致させます。

IDaaSの選定から、GitHubを含む社内SaaSへのSSO・SCIM連携の設計までまとめて任せたい場合は、認証基盤・ID管理システム開発のご相談も受け付けています。

SAML SSO強制前の確認項目と延期条件

• リカバリーコードを保管したか。
• メンバー全員がIdP経由で一度ログインしたか。強制の画面で初めて未認証者に気づくのでは遅い。
• ボット・サービスアカウントにIdPの外部IDがあるか。
• CIのPAT・ユーザーSSHキーがSSO認可済みか、デプロイキーが有効か。GitHub Appへ移せるものは移す。
• 外部サービスのOAuth連携の再認可の段取りを決めたか。
• 外部コラボレーターの棚卸しの手順を別に用意したか。

逆に、急いで強制すべきでない場面もあります。IdPのアカウントが全社に行き渡っていない段階でGitHubだけ強制すると、IdPを持たない部署や委託先がGitHubから締め出されます。前述のGLOBIS社の記録でも、全員がIdP（OneLogin）のアカウントを持てるようになってからGitHub側で強制する、という段取りが今後の展望として書かれていました。SSOの導入速度を決めるのは、GitHubの設定ではなくIdPの整備状況です。それまでは「有効だが強制しない」状態で運用し、ひも付きの進み具合を見て切り替えるのが現実的です。

よくある質問

GitHubのTeamプランでSSOは使えますか？

使えません。SAML SSOとSCIMはGitHub Enterprise Cloudの機能で、SSOが必要ならEnterpriseへの移行が前提です。

GitHub SSOのログインURLはどこですか？

Organizationなら https://github.com/orgs/組織名/sso、enterpriseなら https://github.com/enterprises/enterprise名/sso です。開くとIdPの認証画面に移り、認証後にSSOセッションが作られます。

PATの一覧に「Configure SSO」が出てこないのはなぜですか？

そのOrganizationで一度もIdP認証をしていないためです。SSOログインURLでIdP認証をしてから一覧に戻ってください。fine-grained PATには「Configure SSO」がなく、作成時にOrganizationをリソースオーナーに選ぶと認可されます。

gh CLIでSSOのOrganizationのリポジトリが見えないときはどうしますか？

SSO認可不足が考えられますが、利用中のアカウントやトークンの権限、リポジトリへのアクセス権も確認してください。エラーに「Authorize in your web browser:」のURLがあれば開いて認可し、なければSSOログインURLでセッションを作ってから gh auth refresh で認可をやり直します。

SAMLとSSOは何が違いますか？

SSOは1回の認証で複数のサービスに入れる仕組みの総称で、SAMLはそれを実現するプロトコルの1つ（SAML 2.0）です。GitHubのSSOはSAML 2.0で実装されていて、EMUかつEntra IDの構成に限ってOIDCも選べます。SSOの実現方式の全体像はシングルサインオン（SSO）とは？で解説しています。

関連記事

• SAMLとは？認証フロー・IdP/SPの仕組みとOAuth・OIDCとの使い分けを実装視点で解説
• GitHub PAT（Personal Access Token）とは？作成方法・classicとfine-grainedの違い・確認と失効【2026年10月】
• ghコマンド（GitHub CLI）とは？インストール方法と使い方・コマンド一覧【v2.101対応】
• OIDC（OpenID Connect）とは？IDトークンの検証手順とOAuth 2.0との違いを解説
• SAML NameIDFormatとメタデータの不一致でSSOが失敗する原因の切り分け