はじめに
以前の記事で認証/認可/IdPについて以下でまとめました。
今回もまたAWS SAP問題を解いていてあいまいな理解をしているフェデレーション、SSOについてまとめてみようと思います。
今回の登場するのはGoogleとQiitaです。
普段皆さんが何気なく使用している、Googleの認証情報を使って別のサービスにサインインするあれを例にしたいと思います。
フェデレーション
Googleの認証情報を持っているならQiitaはその認証情報を信頼するから、その認証情報でQiitaにログインしていいよ、という仕組み。
流れ図
まずはこの場の意味の正確な意味を知る前に以下の流れ図を見て全体像を把握しましょう。
上記流れを箇条書きにすると以下です。
1. Qiitaにログインする際、「Googleが認証した結果を信頼するよ」となる
2. QiitaはGoogleにリダイレクトする
3. Googleで認証し、IdPトークンを発行する
4. ブラウザ経由でQiitaへGoogleのトークンが渡る
5. Qiitaがそのトークンの署名を検証する
6. 問題なければQiitaにログイン完了
ではこの流れの中のどこがフェデレーションなのでしょうか？
2～5までの内容がフェデレーションになります。
つまりここでは、「QiitaがGoogleを信頼している仕組み」 =「フェデレーション」ということになります。
強調しますが、フェデレーションは「信頼の仕組み」です。
SSO (Single Sign On)
ではSSOはなんなのか？
こちらは「ユーザーの体験」です。
一度の認証で複数のサービスを利用できる体験です。
Googleに認証していれば、QiitaもZennもYoutubeもそれぞれにログインせずともサービスを利用できます。
GoogleをIdPとして採用しているサービスであれば、複数のサービスに再認証する必要なくログインすることができます。
これがSSOです。
まとめ
フェデレーション = 信頼の仕組み
Googleの認証情報をQiitaが信頼してQiitaにログインする
SSO = 一度の認証で複数サービスを利用できる体験
Googleに認証していれば、QiitaもZennもYouTubeも利用できる