SSOの基本
大きく分けてCookie型とリバースプロキシ型に分かれる。
これらは基本的に認証の窓口としての機能を担い、実際の処理は認証サーバーに依頼し処理させる。
Cookie型
SSOの範囲は同一ドメイン内のページに限られる。
- webサーバーにエージェントをインストール
- 認証サーバーがCookieに認証情報を含めクライアントに返す
- 別のwebサーバーへのアクセス時、クッキー情報を元に認証を行う
リバースプロキシ型
Cookie型同様に、同一ドメイン内のページに限られる。
ID/PASSを用いる方法とデジタル署名を用いる方法がある。
- リバースプロキシが認証役を担う
- 認証後、リバースプロキシが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 など）
-
流れ
- ユーザーがSP（例: AWS）にアクセス
- SPがIdP（例: Google Workspace）にリダイレクト
- IdPでユーザーが認証される
- 認証後、SAMLアサーションがSPに送信される
- 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）を利用し、ユーザー情報を伝達
-
流れ
- ユーザーがOIDCプロバイダ（例: Google）にログイン
- 認証成功後、アクセストークン（JWT）を取得
- クライアントがJWTを含めて各サービスにリクエスト
- サーバー側でJWTを検証し、ユーザーを認証
JWT (JSON Web Token)
トークンベースの認証方式であり、認証情報をステートレスに管理できる。
JWTは電子署名付きのJSONデータであり、改ざんが検出可能。
-
特徴
- 認証状態を維持するために利用
- クライアント側でのトークン管理が可能
- API間の認証やマイクロサービス間認証でよく使われる
-
構成
- ヘッダー（Header）: 署名アルゴリズム情報
- ペイロード（Payload）: ユーザー情報や有効期限
- 署名（Signature）: 署名鍵でのハッシュ値
-
流れ
- 認証サーバーがJWTを発行
- クライアントが各サービスへJWTを付与してリクエスト
- サーバー側がJWTを検証し、認証を行う
リバースプロキシ型
OAuth2.0
認可（Authorization）を担うプロトコルであり、SSOの一部として利用されることもある。
特にAPI認証やマイクロサービス間の認可で広く使われる。
-
特徴
- クライアントが直接認証情報を扱わない
- アクセストークンを発行し、各サービスが認可を行う
- 認証そのものはOIDCなどと組み合わせる
-
流れ
- クライアント（アプリ）が認可サーバーに認可リクエストを送信
- ユーザーがログインして認可を許可
- 認可サーバーがアクセストークンを発行
- クライアントがアクセストークンを用いてリソースサーバーにアクセス
- リソースサーバーがアクセストークンを検証し、リクエストを許可
-
適用例
- API Gateway によるSSO
- AWS Cognito / Google Sign-In との連携
- Webアプリ + モバイルアプリ間の統合認証