「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
- Pairwise Pseudonymous Identifier (PPID)
- SAMLや、OIDCにある概念。
- pairwise の対義語は publicになる。
詳細 †
導入の目的 †
- 一般的に、結託したRPによる名寄せを防ぐ目的で導入される。
- Pairwise Pseudonymous Identifier (PPID)とは、
- ある Relying Party(RP) に対してのみ, ある Entity の識別子として提供される値.
- 他の RP には, 当該 PPID を当該 Entity と関連付けることはできない.
効果と事例 †
しかし、実際は、名寄せで使用された事例はなく、
セキュリティを高める副作用が確認されたことはある（らしい）。
- userid のみを送信して認証とみなす。
みたいな非推奨をやってしまう人たちの
アプリのセキュリティを高めてはいる。
導入の考察 †
Pairwise Pseudonymous Identifier (PPID)の方がセキュア。
（...当たり前と言えば、当たり前だが。）
トレンド †
ウェブサービス事業者のトレンドを分析する。
- Apple：pairwise
- Facebook：pairwise
- LINE：pairwise
- Twitter：public
- Google：
昔、PairwiseだったものをOIDC対応時にpublicに変更した。
- Yahoo：
アプリ横断の共通ID（Yahoo IDとは異なる）
以下のGistの記事が参考になる。
public †
以下のように実装しなければ、publicでもそれほど問題は無さそう。
- 「userid のみを送信して認証とみなす。」の様な実装をしない。
- トークンに署名する。できればクレームセットにも署名する。
sub=email †
派生の問題
- しかし、外部ログイン時の、sub = emailは、ダメっぽい。
- メールが乗っ取られると、外部ログイン経由で乗っ取られる。
- sub = email（username）だと、Pairwiseを実装し難い。
- 従って、外部ログイン時は、
- sub=useridとするか、
- 別の方法（claim）でuseridを連携する。
- publicを選択しているGoogleでも以下のように言っているらしい。
- 「Emailはユニークではない可能性があり、
ユーザーを識別する主キーとしては適さない」
- STSとして機能する場合に関しては、
scopeで要求する事でuseridをクレームに含めることはできるので、
以下の様に、emailの特性毎に使い分ける必要がある。
・企業メアド前提なら、sub = emailで実装しても良い。
・フリーメール等が許容されるなら、useridも要求する。
- 関係が密であれば、Id連携（≒useridの要求）は不要。
（トークン検証が済めばログインするなど）
- 関係が疎であれば、Id連携（≒useridの要求）をする。
（トークン検証後、ローカルuseridと連携useridを紐付ける）
参考 †
OpenID Connect †
OSSコンソーシアム †
Tags: :IT国際標準, :認証基盤, :クレームベース認証
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
