🗝️

SSOの基本についてまとめた

2025/02/13に公開

SSOの基本

大きく分けてCookie型とリバースプロキシ型に分かれる。
これらは基本的に認証の窓口としての機能を担い、実際の処理は認証サーバーに依頼し処理させる。

Cookie型

SSOの範囲は同一ドメイン内のページに限られる。

  1. webサーバーにエージェントをインストール
  2. 認証サーバーがCookieに認証情報を含めクライアントに返す
  3. 別のwebサーバーへのアクセス時、クッキー情報を元に認証を行う

リバースプロキシ型

Cookie型同様に、同一ドメイン内のページに限られる。
ID/PASSを用いる方法とデジタル署名を用いる方法がある。

  1. リバースプロキシが認証役を担う
  2. 認証後、リバースプロキシがwebサーバーにアクセスする

実際のサービスで見られるSSO方式

Cookie型

SAML (Security Assertion Markup Language)

認証情報、属性情報、アクセス制御情報をドメインを超えて伝達可能なプロトコル。
主に企業向けのSSOで利用される。
SP(Service Provider)とIdP(Identity Provider)で構成され、IdPがユーザーを認証し、SPにSAMLアサーションを渡すことでSSOを実現する。

  • 特徴

    • XMLベースのプロトコル
    • 認証情報を暗号化して安全にやり取り可能
    • 主に企業向けのSSOに採用される(Google Workspace, AWS IAM など)
  • 流れ

    1. ユーザーがSP(例: AWS)にアクセス
    2. SPがIdP(例: Google Workspace)にリダイレクト
    3. IdPでユーザーが認証される
    4. 認証後、SAMLアサーションがSPに送信される
    5. SPがアサーションを検証し、SSOが成立する

OIDC (OpenID Connect)

OAuth2.0の上に構築された認証フレームワークであり、JSON Web Token(JWT) を用いた認証情報のやり取りが可能。
GoogleやAWS Cognitoなど、モダンなSSOで広く利用されている。
OIDCトークンは短命のため、セキュリティリスクが少ない。
GitHub ActionsでAWS Access Key IDやAWS Secret Access Keyを環境変数に設定が不要という点から、先日OIDCを使ってAWSにデプロイする仕組みを導入した。

  • 特徴

    • OAuth2.0を拡張し、認証(Authentication)を追加
    • JSONベースのプロトコルで軽量
    • IDトークン(ID Token)を利用し、ユーザー情報を伝達
  • 流れ

    1. ユーザーがOIDCプロバイダ(例: Google)にログイン
    2. 認証成功後、アクセストークン(JWT)を取得
    3. クライアントがJWTを含めて各サービスにリクエスト
    4. サーバー側でJWTを検証し、ユーザーを認証

JWT (JSON Web Token)

トークンベースの認証方式であり、認証情報をステートレスに管理できる。
JWTは電子署名付きのJSONデータであり、改ざんが検出可能。

  • 特徴

    • 認証状態を維持するために利用
    • クライアント側でのトークン管理が可能
    • API間の認証やマイクロサービス間認証でよく使われる
  • 構成

    • ヘッダー(Header): 署名アルゴリズム情報
    • ペイロード(Payload): ユーザー情報や有効期限
    • 署名(Signature): 署名鍵でのハッシュ値
  • 流れ

    1. 認証サーバーがJWTを発行
    2. クライアントが各サービスへJWTを付与してリクエスト
    3. サーバー側がJWTを検証し、認証を行う

リバースプロキシ型

OAuth2.0

認可(Authorization)を担うプロトコルであり、SSOの一部として利用されることもある。
特にAPI認証やマイクロサービス間の認可で広く使われる。

  • 特徴

    • クライアントが直接認証情報を扱わない
    • アクセストークンを発行し、各サービスが認可を行う
    • 認証そのものはOIDCなどと組み合わせる
  • 流れ

    1. クライアント(アプリ)が認可サーバーに認可リクエストを送信
    2. ユーザーがログインして認可を許可
    3. 認可サーバーがアクセストークンを発行
    4. クライアントがアクセストークンを用いてリソースサーバーにアクセス
    5. リソースサーバーがアクセストークンを検証し、リクエストを許可
  • 適用例

    • API Gateway によるSSO
    • AWS Cognito / Google Sign-In との連携
    • Webアプリ + モバイルアプリ間の統合認証

Discussion