マイクロソフト系技術情報 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も要求する。
  • 汎用認証サイトのSPのログイン
  • 関係が密であれば、Id連携(≒useridの要求)は不要。
    (トークン検証が済めばログインするなど)
  • 関係が疎であれば、Id連携(≒useridの要求)をする。
    (トークン検証後、ローカルuseridと連携useridを紐付ける)

参考

OpenID Connect

OSSコンソーシアム


Tags: :IT国際標準, :認証基盤, :クレームベース認証


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2019-09-03 (火) 10:16:20 (79d)