シングルサインオン

Single Sign On

SSO と略される。

一度サインオン(ログイン)したら、他の関連サイトに行ってもログイン状態が維持される仕組み。

どうして SSO が必要なのか?

いちいちWebアプリごとにログインするのが手間。

複数のWebアプリを使っていると、どれかを閉じたりタイムアウトすると再ログインが必要になる。

ログインの実装自体が手間。

ログイン実装は脆弱性を持ちやすい。(個別に実装すると個別に脆弱性ができてしまう)

どうしてWebアプリ関連として書くのか

ほとんどのユースケースがWebのシングルサインオン

スタンドアローンのアプリケーションであっても、認証APIはほぼWeb経由

実装方法

誰が認証情報を入力するか、どこで認証するか、認証結果としてのトークンをどう取り回すか、という問題になる。

当然ながらログインアカウントを統一して取り扱うための認証サーバーが必要。

Cookie はドメインごとにしか送る事ができないため、クロスドメイン(ドメインをまたぐ方式)での Cookie の保持方法が必要となる。

最近はこれが難しくなりつつある。

SSOの方式の分類(厳密ではない)

エージェント方式

クライアント、サーバーまたはサーバー側アプリケーションにエージェントを入れ、エージェントが認証する。

リバースプロキシ方式

リバースプロキシが認証する。

サーバー側アプリケーションは認証済みのセッションだけを受け取る。

代理認証方式

エージェントがユーザーの代わりにサーバー側アプリケーションへのログインを実施する。

フェデレーション方式(federation)

クライアントからのリクエストに、トークンがないか、トークンを始めて受け取った時に、認証プロバイダに問い合わせる。

未認証の場合には認証プロバイダにリダイレクトしてそこで認証してもらう。

認証後はそのトークンを持って、またアプリケーションに戻ってもらう。

ユーザーがトークンを持っているなら別サーバーは認証プロバイダに問い合わせるだけで済む。

透過型(?)

通信トラフィックを監視して、必要に応じて認証情報を追加する。(いまいち実装方法が分からない)

リバースプロキシと何が違う?

参考