本記事は、2026年10月29日時点で公開されている資料をもとにした一般的な観点の整理です。個別の調達や設計の判断は、各自治体の所管部門と、システムを提供する事業者、必要に応じて専門家に確認してください。引用した資料は改訂が続くため、実際の作業の時点で最新の内容を確認してください。

まず区別する｜住民向けの SSO と職員向けの SSO

「自治体の SSO」という言葉は、2 つの異なるものを指して使われます。仕様書や打合せで混ざると、求める要件が食い違うため、最初に区別します。調達全般での切り分けは、「自治体の認証基盤 調達チェックリスト」で整理しています。

表は横にスクロールできます

観点住民向けの SSO職員向けの SSO
使う人住民自治体の職員
入る先住民ポータル、各種申請、図書館などの住民向けサービス庁内の業務システム、クラウドサービス
守る対象住民の個人情報と、手続を行う人が本人であること庁内の情報資産と業務
関係する主な資料DS-511（国の行政機関向けの本人確認の資料。自治体には参考）、OpenID Connect などの標準規格総務省「地方公共団体における情報セキュリティポリシーに関するガイドライン」（三層の構え、LGWAN 接続系など）
本記事での扱い対象対象外

職員向けについて、総務省のガイドライン（令和6年10月版）は、情報システムを「マイナンバー利用事務系」「LGWAN 接続系」「インターネット接続系」に分け、通信経路を分割する対策を「三層の構え」（いわゆる三層分離）として示しています。マイナンバー利用事務系では、二つ以上の認証手段を併用する認証（多要素認証）を利用するものとされています。一方で、このガイドラインの本文には「シングルサインオン」の語は見当たりませんでした（2026年10月29日に本文を検索して確認）。職員向けの SSO を設計するときは、ネットワークの区分ごとの要件を踏まえる必要があり、住民向けの連携の考え方をそのまま当てはめることはできません。本記事はこの先、住民向けの SSO に絞って説明します。

OpenID Connect とは｜ログイン結果を別のサービスに渡す標準規格

OpenID Connect Core 1.0 は、OAuth 2.0 の上に作られた、シンプルな ID の層と説明されています（OpenID Foundation の原本）。ここでは、自治体の担当者が仕様書を読むために必要な範囲に絞って整理します。

登場するもの

OIDC では、ログインを受け付ける側と、その結果を受け取る側が登場します。国の標準ガイドライン DS-511 にも同じ役割を指す用語があります。DS-511 は方式（OIDC や SAML）を指定していないため、下の表の対応は、本記事による整理の例です。

表は横にスクロールできます

本記事での呼び方OpenID Connect の用語DS-511 の用語（対応の例）自治体での例
ID プロバイダOpenID Provider（OP）ID プロバイダ住民の本人確認を行い、結果を渡す基盤
利用側サービスRelying Party（RP）、クライアント依拠当事者住民ポータル、図書館や各種申請のシステム
ログイン結果ID トークンアサーション誰がいつログインしたかを示す、署名つきのデータ

デジタル庁のデジタル認証サービスの実装ガイドラインも、OP（OpenID Provider）や RP（Relying Party）の用語を OpenID Connect Core 1.0 に基づくものとして定義しています。

OAuth 2.0 との関係

OAuth 2.0（RFC 6749、2012年10月）は、あるサービスが別のサービスの情報を利用してよいという許可（認可）を扱う枠組みです。OpenID Connect は、その上に「ログインした人が誰か」を渡す仕組みを加えたものです。認可の枠組みだけでは、ログインした人が誰かを共通の形で伝えることができないため、OIDC が使われます。

ID トークンに入っているもの

ID トークンは、JSON Web Token（JWT）の形式で表される、ログインの結果を運ぶデータです。OpenID Connect Core 1.0 は、次の 5 つのクレーム（項目）を必須としています。

  • iss — 発行者。ID プロバイダを識別する URL です
  • sub — 利用者の識別子。発行者の中で一意で、再び割り当てられることのない値とされています
  • aud — 宛先。利用側サービスのクライアント ID を含まなければなりません
  • exp — 有効期限。この時刻以後は受け入れてはならないとされています
  • iat — 発行時刻

このほか、認可リクエストに nonce を付けた場合、ID トークンには同じ値の nonce が含まれます。なお、ID トークンの有効期限（exp）は、ID プロバイダと利用側サービスの間のログイン状態（セッション）の長さとは別のものと明記されています。

ログインの流れ｜認可コードフロー

住民向けのログインでは、認可コードフローと呼ばれる流れが標準的です。OpenID Connect Core 1.0 の 3.1 節に定められた流れを、6 つの段階に整理します。

住民のブラウザ、利用側サービス、ID プロバイダの間で、ログインの開始、ID プロバイダへの移動、本人確認、認可コードの返却、ID トークンとの交換、ID トークンの検証の 6 段階が進む認可コードフローの図
認可コードフローの流れ。破線はブラウザを経由した移動で、④の認可コードはブラウザを経由して利用側サービスへ渡る。⑤は利用側サービスと ID プロバイダの直接の通信
  1. ログインを開始 — 住民が利用側サービスでログインを選びます
  2. ID プロバイダへ移動 — 利用側サービスが認可リクエストを作り、住民のブラウザを ID プロバイダへ移します
  3. 本人確認 — 住民が ID プロバイダで本人確認を行います。マイナンバーカード、LINE、メールアドレスなど、手段は ID プロバイダ側で決まります
  4. 認可コードを返す — ID プロバイダが、認可コードを付けて、ブラウザを利用側サービスへ戻します。認可コード自体にはログインの結果は入っていません
  5. ID トークンと交換 — 利用側サービスが、認可コードを ID プロバイダのトークンエンドポイントへ直接送り、ID トークンを受け取ります
  6. ID トークンを検証してログイン完了 — 利用側サービスが ID トークンの内容を検証し、利用者の識別子（sub）を取り出します

認可リクエストには、次の 3 つの値を付けるのが一般的です。

  • state — リクエストとコールバックの間で状態を保つための値です。OpenID Connect Core 1.0 は、典型的には CSRF（利用者の意図しない操作をさせる攻撃）の対策に使うと説明しています
  • nonce — 利用側のセッションと ID トークンを結び付け、再利用（リプレイ）攻撃を緩和するための値です。ID トークンに同じ値が入って戻ります
  • PKCE — 認可コードを途中で横取りして使われる攻撃への対策です（RFC 7636、2015年9月）。利用側が秘密の値（code_verifier）を作り、そこから導いた値（code_challenge）を認可リクエストに付け、トークンの請求時に元の値を示します

RFC 9700（OAuth 2.0 のセキュリティのベストプラクティス、BCP 240、2025年1月）は、公開クライアントには PKCE を使わなければならず、機密クライアントにも使うことを推奨しています。また、アクセストークンを認可レスポンスで直接返す方式（インプリシット）は使うべきではないとしています。リダイレクト URI は、完全一致の文字列比較で照合することも示されています。

国のサービスの例では、デジタル認証サービスの実装ガイドライン（2026年8月25日更新）が、認証・署名のプロセスを OAuth 2.0 と OpenID Connect の認可コードフローに基づくものとし、インプリシットフローとリソースオーナーパスワードクレデンシャルズフローは採用していないと記載しています。マイナアプリ側の扱いは、「マイナアプリ統合で、自治体の本人確認はどう変わるか」で整理しています。

SAML と OpenID Connect の違い

ID 連携の方式には、OpenID Connect のほかに SAML 2.0 があります。どちらが優れているかは一概には言えず、実際には連携先のサービスがどちらに対応しているかで決まることが多くなります。原典で確認できる範囲の違いは次のとおりです。

表は横にスクロールできます

観点SAML 2.0OpenID Connect 1.0
規格の発行元と版OASIS。『Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0』、OASIS Standard、2005年3月15日OpenID Foundation。『OpenID Connect Core 1.0 incorporating errata set 2』、2023年12月15日
位置づけ認証・属性・認可に関する、XML 形式のアサーションと、それを伝えるプロトコルを定義OAuth 2.0 の上に、認証の層を加えたもの
ログイン結果の形式XML 形式のアサーションID トークン（JSON Web Token）
本記事で確認した国の資料での記載記載なしデジタル認証サービスの実装ガイドラインと G ビズ ID 接続システム向けガイドラインが、OpenID Connect の認可コードフローを採用

なお、DS-511 と総務省のガイドラインには、OpenID Connect も SAML も記載がありません（本文を検索して確認）。「国が OIDC を求めている」と読める書き方は、避ける必要があります。仕様書では、方式を指定したうえで、連携先の対応状況に応じて代替の方式を認めるかどうかを書いておくと、調達後の連携先の追加が円滑になります。

国の資料で見る｜フェデレーションで確認すること

DS-511「行政手続等での本人確認におけるデジタルアイデンティティの取扱いに関するガイドライン」（2025年9月30日、デジタル社会推進標準ガイドライン）は、身元確認や当人認証を他者に依拠して行うことを「フェデレーション」と定義しています。表 3-15「アサーションに関する対策基準」では、依拠当事者（利用側）が ID プロバイダから受け取ったアサーションを、次の 6 点で検証することとされています。

DS-511 の適用対象は、国の行政機関が提供する行政手続・行政サービスです。自治体には直接適用されませんが、検証の考え方として参考にできます。DS-511 は OpenID Connect にも SAML にも触れていないため、右列の対応は本記事による整理の例です。

表は横にスクロールできます

DS-511 表 3-15 の確認事項OpenID Connect で見る項目の例（本記事の整理）
想定する ID プロバイダから発行されたものであることiss が、あらかじめ登録した ID プロバイダの値と一致する
第三者により偽造・改ざんされたものでないこと署名を、ID プロバイダの公開鍵で検証する
自身が要求したリクエストに対して発行されたものであること認可リクエストに付けた nonce が、ID トークンに同じ値で入っている
自身に向けて発行されたものであることaud に、自分のクライアント ID が含まれる
再利用されたものでないことnonce を使い切りにする。リプレイ攻撃の検知方法は利用側が決める（OpenID Connect Core 1.0 の記載）
有効期限内であること現在時刻が exp より前である
DS-511 の確認事項と、OpenID Connect で見る項目の例（iss、aud、exp、nonce、署名の検証）の対応を示す図
DS-511 は方式を指定していない。右の項目は本記事の整理による例

DS-511 は、このほか、ID プロバイダが複数の認証方式に対応している場合に、身元確認や当人認証の保証レベルをアサーションに含めて連携すること、フェデレーションの開始は原則として依拠当事者側から行うことも示しています。認可コードフローでは、利用側サービスがログインを開始するため、この点とも整合します（本記事の整理）。

国の公開例｜デジタル認証サービスと G ビズ ID

国の事業者向け・行政機関向けのサービスには、OpenID Connect を採用している公開資料があります。いずれも、各サービス自身の接続仕様であり、自治体に採用を求める基準ではありません。

表は横にスクロールできます

資料版・日付対象OpenID Connect に関する記載
デジタル認証サービス「行政機関等・民間事業者向け実装ガイドライン」公開 2025年9月18日、更新 2026年8月25日行政機関等・民間事業者が、マイナアプリと連携する API を使う場合認可コードフローに基づく。認可リクエストに PKCE（code_challenge_method は S256）を設定。認可リクエストごとに新しい nonce を生成。ID トークンの署名アルゴリズムは ES256。iss と aud の検証を示す。ログアウトは back-channel logout の仕組みを記載
G ビズ ID「接続システム向けガイドライン」2.11 版、2026年10月20日法人・個人事業主の認証。行政サービス担当者向け認証結果を、OpenID Connect の Authorization Code Flow の標準に従って提供する。OpenID Connect の標準に準拠したシングルサインオン機能を提供

G ビズ ID の対象は法人・個人事業主であり、住民向けではありません。住民向けの連携を設計する自治体が、同じ方式を使う場合の「書き方の例」として読むのが適切です。

既存の ID をどうつなぐか｜紐付けと移行

すでに自治体のサービスごとに利用者番号やアカウントがある場合、SSO の導入では、既存の利用者と新しい共通の ID を結び付ける作業が生じます。考え方の例を示します（以下は本記事の整理です）。

  • 紐付けの鍵に sub を使う — OpenID Connect Core 1.0 は、sub を、発行者の中で一意で再び割り当てられない識別子と定めています。氏名やメールアドレスのように変わりうる値より、紐付けの鍵に向いています
  • 初回ログイン時に本人であることを確かめる — 既存のアカウントと sub を結び付ける最初の一回で、別人のアカウントを結び付けないよう、確認の手順を定めます
  • 利用側サービスの利用者番号を残す — 切替後も、窓口や問い合わせ対応で既存の番号が使えるようにしておきます
  • 移行の手順と期間を仕様書に書く — 一括の取り込みか、ログイン時の紐付けか、併用か。どの事業者が、いつまでに、何を行うかを分けて書きます

仕様書に書く 8 つの観点

ここまでの内容を、仕様書に書く観点として整理します。「参考にする資料」は、書くときの根拠を確認するための目安です。

表は横にスクロールできます

#観点仕様書に書く内容の例参考にする資料
1方式連携の方式（OpenID Connect など）と版。連携先が別の方式にしか対応しない場合の扱いOpenID Connect Core 1.0（errata set 2）
2ログインの流れ認可コードフローを使うこと。PKCE を設定すること。インプリシットは使わないことOpenID Connect Core 1.0 3.1 節、RFC 7636、RFC 9700
3リダイレクト URI連携先ごとに事前登録し、完全一致で照合すること。登録と変更の手順OpenID Connect Core 1.0 3.1.2.1、RFC 9700
4ID トークンの検証項目署名、iss、aud、exp、nonce の検証。署名アルゴリズムと鍵の更新の方法OpenID Connect Core 1.0 3.1.3.7、DS-511 表 3-15（参考）
5受け渡す情報連携先ごとに、受け渡す項目（scope とクレーム）を最小限にすること。項目の一覧OpenID Connect Core 1.0 5 章
6既存 ID との紐付けと移行sub による紐付け。初回の確認の手順。移行の担当と期間OpenID Connect Core 1.0（sub の定義）
7連携先の追加手順と費用連携先を増やすときの申請、試験、費用の考え方。事業者が連携先に求める情報調達チェックリスト
8ログアウト・セッション・障害時ログアウトを連携先へ伝えるか。ID トークンの有効期限とセッションの長さを分けて決めること。障害時の案内と連絡OpenID Connect Core 1.0（exp とセッションの記載）、デジタル認証サービス実装ガイドライン（back-channel logout）

国の資料との関係については、次のように書き分けると、後から根拠を確認しやすくなります。

  • 「準拠」ではなく「参照」と書く — DS-511 は国の行政機関が対象であり、デジタル認証サービスと G ビズ ID の資料は各サービスの接続仕様です。自治体の仕様書では、「参考にする」資料として、名称、版、確認日を書きます
  • 要件の本体は標準規格で書く — 方式や検証項目は、OpenID Connect Core 1.0 などの原本を根拠にします。日本語訳（OpenID Foundation Japan）は読み方の補助として使えますが、公開されている日本語訳は errata set 1（2014年11月8日）の版で、原本は errata set 2（2023年12月15日）です。版の違いを確認してから使います
  • 確認日を書く — 資料は更新されるため、仕様書には確認した日付を併記します

調達の全体像は、「自治体の認証基盤 調達チェックリスト」にまとめています。同意の記録、操作ログ、可用性、契約終了時の扱いなど、SSO 以外の観点はそちらを参照してください。

RinX の場合

当社の自治体向け統合 ID 基盤 RinX（リンクス）は、本人確認・マイページ・外部連携をひとつの基盤で提供します。サービスページで公開している、連携に関する内容は次のとおりです。

  • ID 連携 — OpenID Connect によるシングルサインオン（一度のログインで複数のサービスを利用）と、住民ポータルなどへの利用者情報の自動連携に対応しています。連携方式はサービスごとに異なるため、ご相談の段階で連携先の仕様を確認して決めます
  • 本人確認の手段 — マイナンバーカードによる本人確認（公的個人認証）、LINE、メールアドレスのログインに対応しています。利用する手段は、自治体ごとにご相談のうえ決定します
  • 住民の利用環境 — マイページは Web ブラウザで利用でき、RinX 専用アプリは不要です

上の 8 つの観点に沿った個別の要件（連携の方式や検証項目など）は、お問い合わせの際にご相談ください。

まとめ

  1. SSO には、住民向けと職員向けがある。職員向けは、総務省のガイドラインが定める三層の構えやネットワークの区分を踏まえる必要があり、住民向けとは分けて考える
  2. OpenID Connect は、ID プロバイダが利用側サービスへログイン結果（ID トークン）を渡す標準規格で、住民向けの連携では認可コードフローと PKCE が基本になる
  3. SAML と OpenID Connect のどちらを使うかは、連携先の対応状況で決まる。本記事で確認した国の資料には、自治体に OpenID Connect の利用を求める記載はない
  4. 国の資料（DS-511、デジタル認証サービス、G ビズ ID）は、参考として使う。DS-511 は方式を指定しておらず、OpenID Connect との対応は例である
  5. 仕様書には、方式、流れ、リダイレクト URI、ID トークンの検証、受け渡す情報、既存 ID との紐付け、連携先の追加手順と費用、ログアウトと障害時の扱いの 8 点を書く

RinX の機能・導入の流れ・費用の考え方は、サービスページで確認できます。

サービスを見る

よくある質問

Q1. OpenID Connect と OAuth 2.0 は何が違いますか？

OAuth 2.0 は、あるサービスが別のサービスの情報を利用してよいという許可（認可）を扱う枠組みです。OpenID Connect は、その上に、ログインした人が誰かを渡す仕組みを加えた規格です。ログインの結果は、ID トークンという署名つきのデータで渡されます。

Q2. SSO と ID 連携は同じ意味ですか？

本記事では、SSO を「住民が一度ログインすると、複数のサービスに再ログインなしで入れること」という利用者の体験の意味で使い、ID 連携を、その体験を実現するために ID プロバイダと利用側サービスの間で結果を受け渡す仕組みの意味で使っています。一般には、両者がほぼ同じ意味で使われることもあるため、仕様書では、どちらを指すかを書いておくと誤解を防げます。

Q3. SAML と OpenID Connect のどちらを選べばよいですか？

連携先のサービスが対応している方式で決まることが多くなります。どちらが優れているかを一概に判断することはできません。仕様書では、主に使う方式を指定し、連携先が別の方式にしか対応しない場合の扱いを併記しておく方法があります。

Q4. マイナンバーカードによるログインと OpenID Connect はどういう関係ですか？

別の事項です。マイナンバーカードによる本人確認は、住民が本人であることを確かめる手段です。OpenID Connect は、確かめた結果を、利用側のサービスへ渡す方式です。仕様書では、「本人確認の手段」と「連携の方式」を分けて書くと、一方を変更するときに、もう一方を書き換えずに済みます。

Q5. 一度のログインで複数のサービスに入れると、セキュリティ上の影響は大きくなりませんか？

ID プロバイダの本人確認が破られた場合の影響は、連携先の数だけ広がります。そのため、利用側での ID トークンの検証、有効期限の設定、手続ごとに必要な本人確認の強さの決め方が重要になります。DS-511 は、ID プロバイダが複数の認証方式に対応する場合に、保証レベルなどの情報をアサーションに含めて連携することを示しています（国の行政機関向けの資料で、自治体には参考）。手続ごとの考え方は、調達チェックリストを参照してください。

Q6. 既存の利用者番号や ID はどうなりますか？

切替後も既存の番号を残し、新しい共通の ID（sub）と結び付ける方法が考えられます。初回に本人であることを確かめる手順、一括の取り込みとログイン時の紐付けのどちらを使うか、移行の担当と期間を、仕様書に書いておきます。

Q7. 職員向けのシングルサインオンとはどう違いますか？

使う人と守る対象が違います。住民向けは、住民の本人確認と住民向けサービスへのログインを扱います。職員向けは、職員が庁内の業務システムやクラウドサービスに入るためのもので、総務省の「地方公共団体における情報セキュリティポリシーに関するガイドライン」が示す三層の構えやネットワークの区分の影響を受けます。求める要件が異なるため、仕様書は分けて書きます。

出典・参考資料

いずれも2026年10月29日に内容を確認しています。

  1. OpenID Foundation『OpenID Connect Core 1.0 incorporating errata set 2』（Final、2023年12月15日）openid.net
  2. OpenID Foundation Japan『OpenID Connect Core 1.0 日本語訳』（incorporating errata set 1、2014年11月8日。原本とは版が異なる）openid-foundation-japan.github.io
  3. IETF『RFC 6749 The OAuth 2.0 Authorization Framework』（2012年10月）rfc-editor.org
  4. IETF『RFC 7636 Proof Key for Code Exchange by OAuth Public Clients』（2015年9月）rfc-editor.org
  5. IETF『RFC 9700 Best Current Practice for OAuth 2.0 Security』（BCP 240、2025年1月）rfc-editor.org
  6. OASIS『Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0』（OASIS Standard、2005年3月15日）docs.oasis-open.org
  7. デジタル庁『DS-511 行政手続等での本人確認におけるデジタルアイデンティティの取扱いに関するガイドライン』（2025年9月30日）digital.go.jp
  8. デジタル庁『行政機関等・民間事業者向け実装ガイドライン』（デジタル認証サービス。公開 2025年9月18日、更新 2026年8月25日）developers.digital.go.jp
  9. デジタル庁『G ビズ ID 接続システム向けガイドライン』（2.11 版、2026年10月20日）gbiz-id.go.jp
  10. 総務省『地方公共団体における情報セキュリティポリシーに関するガイドライン（令和6年10月版）』（別紙2。令和6年10月2日改定）soumu.go.jp
  11. 総務省報道資料『「地方公共団体における情報セキュリティポリシーに関するガイドライン」等の意見募集の結果及び改定版の公表』（令和6年10月2日）soumu.go.jp
自治体 · 認証基盤 · 調達自治体の認証基盤 調達チェックリスト｜仕様書に書く10の観点2026年10月29日自治体 · 本人確認 · マイナアプリマイナアプリ統合で、自治体の本人確認はどう変わるか｜デジタル認証サービスの対応整理2026年10月29日関連サービスRinX（リンクス）｜マイナンバーカードで本人確認できる自治体向け統合 ID 基盤サービスを見る →

関連サービス

RinX（リンクス）

本人確認・マイページ・外部連携をひとつの基盤で提供する、自治体向けの統合 ID 基盤です。

サービスを見る