SSO

Single Sign-On

security web beginner

1回ログインするだけで、連携している複数の異なるWebサービスやアプリに自動ログインできる仕組み。

概要（サマリー）

SSO（Single Sign-On / シングルサインオン）とは、1回のユーザー認証（ログイン操作）を行うだけで、連携している複数の異なるWebサービスや社内システムにログインしやすくする仕組みである。
遊園地の「ワンデーパスポート（フリーパスのリストバンド）」にたとえられる。アトラクション（サービス）に乗るたびに毎回チケットを買って財布から小銭を払う（IDとパスワードを入力する）必要がなく、入り口で一度チケットを買ってリストバンド（ログイン状態を示すトークン）を巻けば、すべてのアトラクションに顔パス（自動ログイン）で入れるイメージである。

詳細解説

SSOとは何か

現代の仕事や生活では、Slack、Notion、Gmail、社内基幹システムなど、何十ものWebサービスを利用する。これらすべてに別々のIDとパスワードを設定して毎回手動でログインするのは、ユーザーにとって非常に大きなストレスである。また、パスワードの使い回しや付箋へのメモなど、セキュリティ上の危険な行動（パスワード認証の限界）を引き起こす原因にもなる。
この問題を技術的に解決し、利便性とセキュリティを両立させるのがSSOである。

SSOの代表的な仕組み

SSOを実現するための通信技術には、主に以下のような標準規格がある。

SAML（サムル）認証:
主に企業の社内システムやビジネス用のSaaS同士を繋ぐための規格。ID管理を行うサーバー（認証プロバイダ）が「このユーザーは本物です」という電子証明書（アサーション）を発行し、各サービスがそれを検証してログインを許可する。
OpenID Connect (OIDC) / OAuth:
一般のWebサイトでよく見かける「Googleアカウントでログイン」「GitHubでログイン」といったソーシャルログインのベースとなっている技術。ID情報を含んだ一時的な「トークン（JWTなど）」をやり取りすることでログイン状態を証明する。

SSOを導入するメリット

ユーザーの利便性向上: 覚えるパスワードは「大元の1つ」だけでよくなり、ログインの手間が激減する。
パスワード紛失・漏洩の削減: パスワードを入力する機会そのものが減るため、フィッシング詐欺などでパスワードを盗み見られるリスクが下がる。
管理コストの削減: 社員が退職した際、大元の認証システムのアカウントを1つ削除（無効化）するだけで、連携しているすべてのSaaS（Slack等）へのアクセスを一瞬で遮断できる。

セキュリティ上の注意点：マスターキー問題

SSOは非常に便利だが、「大元のアカウントがハッキングされたら、連携しているすべてのサービスに芋づる式に侵入されてしまう」という単一障害点（マスターキーの紛失）のリスクを抱えている。
そのため、SSOの大元となるアカウントには、通常のID/パスワードだけでなく、「二要素認証（ワンタイムパスワード等）」を組み合わせて保護を強めることが強く推奨される。

AIコーディングとの関係

Webアプリケーションを開発する際、自前でユーザー登録・ログイン画面を作らずに、SSO（GoogleやGitHubアカウントでのソーシャルログイン）を導入することは、開発コスト削減とセキュリティ確保のために非常に有効である。

AIコーディングを利用することで、この認証API連携コードのたたき台をすばやく作れる。

OAuth / OIDC 連携コードの自動生成:
AIに対して、「Next.jsのアプリケーションで、NextAuth.js を使ってGoogleアカウントでのシングルサインオン（OAuth）を実装するコードを書いて」と指示する。
これにより、セッション管理（Cookieやトークンの扱い）を含んだログイン認証コードの出発点を得られる。ただし、リダイレクトURI、環境変数、Cookie設定、CSRF対策などは公式ドキュメントと照合して確認する必要がある。

NextAuth.jsを用いたSSO設定の例（AI生成）:

// pages/api/auth/[...nextauth].js
import NextAuth from "next-auth"
import GoogleProvider from "next-auth/providers/google"

export default NextAuth({
  providers: [
    GoogleProvider({
      // 環境変数から認証情報を読み込む（ソース直書きは絶対NG）
      clientId: process.env.GOOGLE_CLIENT_ID,
      clientSecret: process.env.GOOGLE_CLIENT_SECRET,
    }),
  ],
  // セッションの保存に安全なJWTトークンを使用する設定
  session: {
    strategy: "jwt",
  },
})

よくある勘違い

SSOを導入するとセキュリティは完全に万全になる？

そうではない。
SSOは認証の入り口を安全にするが、ログインした後の「各サービス内の権限管理（誰がどのデータを編集できるか）」までは管理しない。大元のアカウント保護（二要素認証）を怠ったり、ログインしたままPCを放置して他人に触られたりすれば、すべてのシステムが突破される大惨事になるため、個人のセキュリティ意識は引き続き重要である。

SSOと「パスワード管理アプリ」は同じもの？

異なる。
* SSO: 認証システムそのものを一つに統合し、1回のログインで全システムに入れる技術（裏側でトークンなどをやり取りする）。
* パスワード管理アプリ（1Passwordなど）: ユーザーの代わりに、各サービスの異なるIDやパスワードを記憶し、ログイン画面で「自動入力」してくれるツール。システム自体が統合されているわけではない。

「Googleアカウントでログイン」ボタンは、SSOとは無関係？

実は立派なSSOの一形態である。
「Googleアカウントでログイン」「GitHubアカウントでログイン」のようなソーシャルログインは、Googleアカウントという「大元の1つのアカウント」を使って別のサービスに認証情報を渡すものであり、SSOの技術（OpenID Connect / OAuth）を採用している。企業内の基幹システムを1つのIDで繋ぐ「エンタープライズSSO」とは規模と対象は異なるが、仕組みの本質は同じである。SSOを「大規模企業専用の難しい技術」と思い込まず、身近なソーシャルログインも含まれる概念として理解することで、Web認証の全体像が見えやすくなる。

まとめ

SSOは、1回ログインするだけで複数の異なるサービスへ自動的にログインできる認証の仕組み。
GoogleやGitHubログインなどのソーシャルログインもSSOの一種。
パスワードを何個も覚える必要がなくなり利便性が上がるが、大元が突破された時のリスクが高いため、二要素認証との併用が必須。
AIに実装コードを依頼する際は、APIキーやシークレットキーを環境変数で厳密に隠すように指定することが重要。

情報ソース

より詳しくAIに聞いてみよう

ソーシャルログインで使われる「OAuth 2.0」と「OpenID Connect (OIDC)」の明確な役割の違いについて、認可と認証の観点から解説してください。
企業向けのSSOでよく使われる「SAML 2.0」認証において、ユーザーがログインボタンを押してからサービスにログインできるまでの詳細な通信の流れ（アサーションのやり取り）を教えてください。
自作のWebアプリにGoogleログインを導入する際、Google Cloud Consoleで「クライアントID」と「クライアントシークレット」を発行し、リダイレクトURIを設定する大まかな手順を教えてください。
SSOの大元のログインシステムがダウンした場合に備え、連携サービス側の接続を維持したり、管理者用バックドアを用意したりする設計上の回避策（フォールバック）を教えてください。
SSOでよく使われる「JSON Web Token (JWT)」というトークン形式の構造と、改ざんを検知する署名の仕組みについて教えてください。