GitHub SSOの設定手順｜SAML連携・PAT/SSH認可の落とし穴

GitHub SSOは、Microsoft Entra IDやOktaといったIdP（Identity Provider）のアカウントでGitHubにサインインさせ、入退社に合わせてアクセス権を一元管理する仕組みです。利用できるのはGitHub Enterpriseプランのみで、FreeとTeamでは設定項目が現れません。そして導入で最も事故が起きるのは設定画面ではなく、その後です。SSOを強制（enforce）した瞬間、認可していないパーソナルアクセストークンとSSHキーが一斉に弾かれ、CI/CDが止まります。この記事では対応プランの前提から、SAML連携の設定手順、ユーザー側のログインとセッション、そしてPAT・SSHキー・GitHub CLIの認可までを、公式ドキュメントの記述にそって順に押さえます。

まとめ

• SAML SSOとSCIMはGitHub Enterpriseプラン限定。Team（$4/user/月）では使えず、Enterpriseは$21/user/月（GitHub公式のPricing、最初の12か月の表示価格）。
• 設定はIdP側のSign on URL・Issuer・公開証明書の3点をGitHubに登録するだけ。難所ではない。テスト成功を確認してからenforceに進む。
• ユーザー側のSSOセッションは既定24時間で切れる。IdPの設定で変更できる。
• 事故の本体は認可（Authorize）漏れ。classic PATとSSHキーは作成後に組織ごとの認可操作が要る。fine-grained PATは作成時に認可される。ここを飛ばすとgit pushもAPIもCIも通らない。
• enforce前に、OAuth Appで連携している外部CI・ツールの再認可が必要かを棚卸しする。強制のスイッチを入れる作業自体は一瞬でも、影響範囲はGitHubの外まで及ぶ。

GitHub SSOの対応プランとSAML/OIDCの選択基準

対応プランはEnterpriseのみ（Teamでは不可）

GitHubでSAML SSOを使う条件は明快です。組織がGitHub Enterprise Cloudを利用していること。GitHub公式のPricingページでも、SAML single sign-onとSCIMによるユーザープロビジョニングはEnterpriseプランの機能として記載され、FreeとTeamには含まれません。価格はTeamが$4/user/月、Enterpriseが$21/user/月（いずれも最初の12か月として表示される価格）。「Teamプランのままコストを抑えてSSOだけ入れたい」という要望は、GitHubの製品構成上そもそも成立しません。SSO導入の検討は、ライセンスをEnterpriseへ上げる判断とセットになります。

GitHubに払うライセンスとは別に、IdaaS側のライセンス費も発生します。Entra ID、Okta、OneLogin、Google Workspace、Keycloakなど、どのIdPを主軸に据えるかで運用負荷は変わるところ。IdPをこれから選ぶ段階なら、Keycloakのメリット・デメリットとAuth0・Okta・Cognitoの比較や、IDaaS「Okta」の導入支援プランを先に押さえておくとよいでしょう。GitHub側の設定は後から差し替えが利きます。

SAMLとOIDCの選択基準

GitHubのSSOはSAML 2.0が基本です。SAML 2.0に準拠したIdPであれば連携でき、Entra ID、Okta、OneLogin、PingOne、Google Workspaceなどが対象になります。

一方のOIDCは適用範囲が限られます。GitHubのOIDC SSOはEnterprise Managed Users（EMU、企業がアカウント自体を発行・所有する形態）向けで、対応IdPはMicrosoft Entra IDのみ。さらに、1つのEntra IDテナントで持てるOIDC連携は1つのenterpriseに限られ、複数のenterpriseを同じテナントに繋ぐならSAMLを使うことになります。IdP起点のログイン（IdP-initiated）やカスタムクレームにも対応しません。

選択の指針はこうなります。EMUを採用し、IdPがEntra IDで、enterpriseが1つなら、条件付きアクセスポリシー（CAP）まで効かせられるOIDCが有利。それ以外はSAMLを選ぶ。プロトコル自体の優劣ではなく、EMUを使うか・IdPが何かでほぼ自動的に決まる話です。OIDCが土台にしている認可の仕組みそのものは、OAuth 2.0の認可フローと、認証・認可の違いを押さえると理解が早くなります。

Organization単位とenterprise単位の使い分け

SAML SSOは、個々のOrganizationに設定する方法と、enterpriseアカウントに設定する方法があります。enterpriseアカウント側で有効にすると、SSOはそのenterpriseが所有する全Organizationとメンバー全員に対する要件として強制されます。Organizationが1つだけならOrganization単位で足りるものの、複数のOrganizationを抱えるならenterprise単位に寄せたほうが設定は1か所で済みます。EMUを使う場合はenterpriseレベルでしか設定できません。

Organization単位で先に運用を始め、後からenterpriseへ移す経路も公式に用意されています（SAML設定のOrganizationからenterpriseアカウントへの切り替え）。将来Organizationが増える見込みがあるなら、最初からenterprise単位で設計しておくほうが移行の手間は小さくなります。

SAML SSOの設定手順（管理者側）

IdPから取得する3つの値

GitHub側の入力欄はごくシンプルです。IdPのアプリケーション設定画面から次の3点を取得して貼り付けます。

Issuerは任意項目に見えますが、IdPのグループとGitHub Teamを同期させるチーム同期（team synchronization）を使う場合は必須です。後から有効化しようとして詰まりがちなので、最初から入れておきます。GitHub側が発行するACS URL（https://github.com/orgs/ORG-NAME/saml/consumeのような値）とEntityIDは、逆にIdPのアプリ設定へ登録してください。

Test SAML configurationと強制の順序

設定画面には、保存前にSAML連携を検証する「Test SAML configuration」があります。GitHubは、このテストが成功しないとSAMLの設定を保存できない設計です。順序としては、まずSSOを有効化してテストを通し、メンバーがIdP経由でログインして外部IDのひも付け（linked identity）が作られる期間を置く。そのうえで強制（Require SAML SSO authentication）に進みます。

強制を有効にすると、IdPで認証していないメンバーはOrganizationから削除されます。削除されたメンバーには通知メールが届き、SAML SSOで認証し直せば復帰できます。3か月以内に復帰すればアクセス権限や設定も復元されるものの、混乱を避けるなら、強制の前に「誰が未ログインか」をメンバー一覧で確認しておく手順を挟むべきです。

IdP別のつまずきどころ（Entra ID／Okta／Google Workspace）

• Microsoft Entra ID：ギャラリーアプリ「GitHub Enterprise Cloud – Organization」を使うと入力値がほぼ用意されます。NameIdentifier（NameID）に何を送るかで、後からのユーザー同定が変わる点に注意。
• Okta・OneLogin：SCIMプロビジョニングまで一気に設定できるアプリテンプレートがあります。SSOとSCIMではスコープが別なので、APIトークンの権限を分けて確認します。
• Google Workspace：SAML 2.0のカスタムアプリとして設定できます。ただしSCIMプロビジョニングの対応範囲はEntra IDやOktaより狭く、退職者のアカウント自動削除まで求めるなら事前検証が要ります。

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

ログイン導線とSSO開始URL

ユーザーがSSOを有効にしたOrganizationのリソースへアクセスすると、IdPへリダイレクトされて認証を求められます。ブラウザで直前にIdP認証を済ませていれば、そのまま自動的に認可されます。「Sign in with your identity provider」という画面が出るのは、この導線です。

明示的にSSO認証を開始したいときは、次のURLを直接開きます。

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

「SSOのログインURLが分からない」「認証を通し直したい」という場面は、このURLで解決します。EMUの場合は個人アカウントではなく、企業が発行・管理する専用アカウントでのサインインになる点が通常のSSOと異なります。

SSOセッションは24時間で切れる

SSOでログインした状態（SSOセッション）の有効期間は、IdP側で別途指定しない限り24時間です。「昨日は通っていたgit pushが今朝また認証を求めてくる」のは仕様どおりの挙動で、障害ではありません。頻度が業務上つらい場合は、GitHub側ではなくIdPのセッションライフタイム設定で調整します。

現在のセッションの確認と失効は、GitHubの「Settings」→サイドバーのAccessセクション→「Sessions」から行えます。Web sessionsに一覧が出るので、詳細を開いて「Revoke session」を実行すると、そのOrganizationへのSSO認証が取り消されます。端末を紛失したとき、あるいは権限を切り替えた直後に古い認証を残したくないときに使う機能です。

PAT・SSHキー・GitHub CLIの認可（ここで一番詰まる）

SSOの設定そのものより、こちらが導入時の問い合わせの中心になります。SSOを強制したOrganizationのリソースには、認証情報を「そのOrganization用に認可」しない限りアクセスできません。ブラウザでSSOにログイン済みでも、コマンドラインの認証情報は別扱いです。

パーソナルアクセストークン（PAT）の認可

トークンの種類で挙動が違うため、ここを取り違えると原因不明の403・404を追いかけることになります。

認可の前提として、そのOrganizationのIdPで一度は認証し、外部IDのひも付けができている必要があります。CI用のマシンユーザーでこれを忘れると、「トークンは有効なのに対象リポジトリだけ見えない」という状態になります。

SSHキーの認可

SSHキーも同様です。SSOを使うOrganizationのリポジトリへSSHでアクセスするには、キーごとに認可が必要になります。「Settings」→「SSH and GPG keys」から対象キーの「Configure SSO」で認可してください。デプロイ用の鍵を登録したまま認可を忘れ、enforce当日にデプロイが落ちるのが典型パターンです。

GitHub CLIと外部CIが落ちるケース

GitHub CLI（gh）でSSO対象のリポジトリが見えない、リポジトリ一覧に出てこない。この場合も原因はトークンの認可です。gh auth loginをやり直すか、既存トークンをブラウザ側で認可し直すと通ります。

gh auth status
gh auth login --web --scopes repo,read:org

影響はGitHubの中だけに留まりません。GLOBIS社がZennで公開したGitHub SSO導入事例では、SSO導入後にCircleCI・ZenHub・GitHub Mobile・AWS CodeBuildといったOAuth連携が認証を失い、CircleCIではプロジェクトのフォローが解除されデプロイキーが削除されるため再設定が必要になった、と報告されています。SSOを強制する前に、Organizationに紐づくOAuth App・GitHub Appの一覧を棚卸しし、再認可が必要なものをリストアップしておくのが安全です。必須ステータスチェックやReusable WorkflowsでCIをブランチ保護に組み込んでいる場合、認証が切れたワークフローがそのままマージのブロック要因になります。

SCIMプロビジョニングによるアカウントの自動管理

SAML SSOは「ログインの入口」を統制しますが、アカウントそのものの発行・削除までは行いません。入退社に合わせてGitHubのメンバーを自動で増減させるには、SCIMプロビジョニングを併用します。IdPでGitHubアプリへのアクセス権を付与するとメンバーが自動招待され、権限を剥奪するとメンバーが削除される、という連動です。

SSOだけを入れてSCIMを入れない構成はよくあります。その場合、退職者のアカウント削除は手作業のまま残ります。IdPで無効化された時点でGitHubへログインできなくなるため実害は限定的ですが、有償のEnterpriseライセンスは消費し続けます。SSOの目的が「棚卸しコストの削減」なら、SCIMまで含めて設計しないと目的の半分しか達成できません。

enforce前の事前チェック項目

ここまでを踏まえ、強制（enforce）を有効にする前に確認すべき項目を挙げます。順序を守れば、SSO導入で起きる障害はほぼ防げます。

• メンバー全員がIdPで一度ログイン済みか。未ログインのメンバーは強制の時点でOrganizationから外れる。
• CI/CDが使うPAT・SSHキー・デプロイキーを洗い出し、認可済みか。マシンユーザーの外部IDひも付けも忘れやすい。
• OAuth App連携の外部サービス（CI、プロジェクト管理、ChatOps）の再認可手順を用意したか。
• Outside collaborator（外部コラボレーター）の扱い。SSO強制の対象外だがTeamに所属させられないため、Teamベースで権限を配る仕組みとは噛み合わない。
• IdP側の障害時の回復手段。SAMLのリカバリコードをダウンロードして安全な場所に保管する。IdPが落ちた時にこれがないと、管理者自身も入れなくなる。

逆に、SSOを急いで入れるべきでない場面もあります。IdPの導入が全社の一部にとどまっている段階でGitHubだけ強制すると、IdP未整備の部署がGitHubから締め出されます。前掲のGLOBIS社の事例でも、IdPの適用が全社に行き渡っておらず強制まで踏み切れていない状態が報告されました。SSOはGitHub側の設定作業ではなく、IdPの整備状況に律速される施策。そう考えたほうが実態に合います。

よくある質問

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

SSOは「1つの認証情報で複数サービスにログインできる」という仕組み・概念の名前で、SAMLはそれを実現するためのプロトコル（SAML 2.0）の名前です。GitHubのSSOはSAML 2.0で実装されており、EMU＋Entra IDの構成に限りOIDCも選べます。

TeamプランからEnterpriseへ移行すると何が変わりますか？

SAML SSOとSCIMプロビジョニングの設定項目が使えるようになり、監査ログAPIやIP許可リストも利用できます。移行時に注意すべきは既存メンバーの扱いで、SSOを強制した時点でIdP未認証のメンバーはOrganizationから外れます。移行直後に強制せず、全員がIdPでログインしてから強制に切り替えてください。

SSOセッションの確認・失効はどこから行いますか？

GitHubの「Settings」→サイドバーのAccessセクション→「Sessions」を開くと、Web sessionsに現在のセッションが表示されます。詳細から「Revoke session」を実行すると、そのOrganizationへのSSO認証が取り消されます。セッション自体はIdPで指定しない限り24時間で失効します。

SSO有効化後にgit pushやAPI呼び出しが403になります。原因は？

使っている認証情報がそのOrganization向けに認可されていない可能性が高いです。classic PATは作成後に「Configure SSO」から対象Organizationを認可する操作が必要で、SSHキーも同様に認可が要ります。fine-grained PATの場合は、作成時にリソースオーナーとして対象Organizationを選んでいるか確認してください。

Google WorkspaceのアカウントでGitHubにSSOログインできますか？

できます。Google WorkspaceはSAML 2.0に対応しているため、カスタムSAMLアプリとして設定すればIdPとして利用できます。ただしSCIMによるユーザーの自動作成・削除の対応範囲はEntra IDやOktaより限定的なので、プロビジョニングまで自動化したい場合は事前に対応範囲を確認してください。関連する内容として、Saviyntもご覧ください。

関連記事

• OAuth 2.0とは？仕組み・認可フローと認証・認可の違いをわかりやすく解説
• Keycloakとは？メリット・デメリットとAuth0・Okta・Cognito比較で導入を判断【2026年版】
• IDaaS「Okta」導入支援｜ラックのスターターパック3プラン比較と従業員ID管理の課題解決
• Require status checks to passとは？GitHubの必須ステータスチェックを設定する方法
• Reusable Workflows（GitHub Actions）とは？workflow_callでの作成・呼び出しとinputs/secrets/outputsを解説