と、言うことで崎村さんの「非技術者のためのOAuth認証（？）とOpenIDの違い入門」に絡めて考えてみました。
参考：http://www.sakimura.org/2011/05/1087/
認証連携とかID連携っていうのは元々、Identity Federationの日本語訳だと思うのですが、まずはIdentityという用語を「認証」と訳してしまっている段階でアレな訳です。しかしかと言って明快に「これだ！」という和訳がないので仕方なく「ID連携」としてしまっているのが現状ですね。
実際の仕組みの意味的にいうと、RP（Relying Party）側の持っているアイデンティティ情報とIdP（Identity Provider）側の持っているアイデンティティ情報を「紐づける」というのがFederationの元々の意味合いなんですが、ここで混同されるのがSAMLで言えばいわゆるSAMLログオン（SAMLトークンを持っていることで認証する）という話や最近の類似した事例で言えばJWT（JSON Web Token）を使った簡易SSOっていうのがあったりして、ややこしくなるわけです。
そして、ここから拡大解釈されたのがOAuth認証（Access Tokenを持っていることで認証する）。。何だろうなぁ、、思っています
まとめるとこんな感じ。
| ID連携 | 簡易SSO | え？ | |
|---|---|---|---|
| 例 | SAML、OpenID Connectを使ったアイデンティティ情報（認証状態を含む）の紐づけ | SAML認証、JWTを使った簡易SSO | OAuth認証 |
| 何をもって認証するか | そもそも認証にクローズした話じゃない | デジタル署名などで検証可能なトークン（SAMLトークンやJWT）を持っている | （確かに持ち主に発行されたことを検証できない）トークンを持っている |
| 用途 | RPとIdPのアイデンティティ情報の紐づけ | シングルサインオン | シングルサインオン |
この表を見ると簡易SSOって何よ？という話になると思いますが、シングルサインオンに求められる要件を考えると一目瞭然な訳ですが、代表的な例で言えばSLO（シングルログアウト）やセッション管理が出来ない、というところになると思います。
例えば、ちゃんとしたWAM（Web Access Management）ソリューションだとサーバ側でのセッションの強制終了や一つのサイト（RP）からログアウトすれば、すべての関連するRPからログアウトされるシングルログアウト何かが必須要件になると思いますが、SAML認証やJWTを使った簡易SSOでは単純にトークンを持っていること（もちろんトークンの発行先の検証や有効期限の検証はRP側でする前提）はあるものの、都度IdP側に該当トークンの有効性の確認までしない、というあたりがいわゆるシングルサインオンとの違いになってきます。
OAuth認証に至っては誰に発行したものなのか、についての検証すらしない（できない）というあたりが認証としての要件を満たしていないわけです。
現実世界のメタファに当てはめると、以下のような話になると思います。
・SAML認証、JWTでの簡易SSO：免許証など写真付き身分証明書を持ってきた
⇒RP側（アプリ側）で持ってきた人の顔と証明書の顔写真が一致しているか検証可能
・OAuth認証：保険証を持ってきた
⇒RP側では持ってきた人が主張すれば信じるしかない？
認証の話ばかりしましたが、連携の話をすると、RP側で持っているもしくは他のIdPから取得したアイデンティティ情報とFederation（連携：紐づけ）をして一つのアイデンティティとして認識をする、というのが本来のアイデンティティ連携です。この紐づけをする対象の属性の一つとして一番わかりやすいユースケースとして認証状態（どこで、いつ、どうやって認証された、という情報）があるのでFederationがシングルサインオンに使えるため、Federation＝シングルサインオンみたいな話になっているわけです。
そんなこんなで、良くこの界隈では話がされる内容ですが、
・ID＝Identityであって本質的には認証とは関係ない
・Federationも本質的には認証のための仕組みではない
・OAuthは認証には使っちゃダメ
ということです。
＜酔っぱらい＠新幹線にて＞
投稿
