Skip to content

Instantly share code, notes, and snippets.

@mala mala/ppid_survey.md Secret
Created Jul 16, 2019

Embed
What would you like to do?
各社のログインAPIで返ってくるIDは何であるのかと、PPIDの現状について

各社のログインAPIで返ってくるIDは何であるのかと、PPIDの現状について

免責

  • この文章は業務時間中に調べた内容も多分に含まれているが、mala個人の文責で書かれている。
  • 何か間違ったことが書かれていたらコメントで指摘するなり、twitterとかで教えてください。

PPID(Pairwise Pseudonymous Identifier) / 仮名識別子 について

  • 連携するアプリ単位や開発者単位で、異なる userid を返すような仕組みがあり、PPIDと呼ばれている。
  • PPIDの主目的はプライバシーの保護であり、異なるアプリケーション間での名寄せを困難にする。
  • PPIDが使われている場合、副作用で、RP(Relying Party)の実装が不適切だった場合に、影響が緩和されることがある(後述)

アプリを横断して共通のIDを返す Provider

  • Google, Twitter, Yahoo などが該当する。

Google のケース

後述の、FacebookやLINEが、アプリ毎横断の共通のuseridから、PPIDへの移行を進めていったのに対して、Googleは逆にPPIDからpublicなIDへと変更している。

Googleの人に聞いたわけではないので推測ではあるが、理由としては2つぐらい考えられる。

    1. Google+ を始めとしたSocialなAPIとの連携を強化するため
    1. サービス横断で共通の識別子を得ようとして、Emailのパーミッションを求められるのは過剰であるから
  • 「Emailはユニークではない可能性があり、ユーザーを識別する主キーとしては適さない」という記述がある。

  • https://developers.google.com/identity/protocols/OpenIDConnect#obtainuserinfo

The user's email address. This may not be unique and is not suitable for use as a primary key. Provided only if your scope included the string "email".

Twitterのケース

  • 誰でも取得可能な public な数字の id が返ってくる。

  • Twitterはusernameは可変だが、HTMLソースやAPIレスポンスなどで、一意のuseridが含まれている。

  • ※ Twitterは経緯からして、そもそも認証のためのAPIではないので、PPIDにするモチベーションはないだろう。

  • 昔は連番だったが今は違うはず。

Yahooのケース

  • OpenID Configurationエンドポイントで確認することができる https://auth.login.yahoo.co.jp/yconnect/v2/.well-known/openid-configuration
  • アプリを横断して共通のIDを返している。このIDは、Yahoo IDとは異なるため、単純に外部からの推測は可能にはなっていない。
  • ユーザーから認可された個々のアプリのデベロッパーであれば取れる。

アプリ毎、または開発者毎に異なるIDを返す Provider

  • FacebookやLINEがこれに該当する

Facebook のケース

LINE のケース


解説

トークン置換攻撃とPPIDについて

  • あまり明確に解説されているのを見たことがないが、PPIDは副作用として、トークン置換攻撃(token substitution attack)に対する影響が緩和される。
  • トークン置換攻撃は、異なるアプリ向けに発行された token をバックエンドサーバーに送信して、バックエンドサーバーが「どのAppに対して発行されたtokenなのか」を検証せずに受け入れてしまうような脆弱性のことだ。
  • 取得されるuseridがApp毎に異なるIDになっているので、結果として「既存のユーザーとしてのログイン」には失敗する。(本来はそのAppに対して発行されたtokenではないのに新規ユーザー作成が行われる、などの影響は想定できる)

ID置換攻撃?について

  • tokenではなく、本当に単純にクライアント側SDKで取得されたuseridのみをバックエンドサーバーに送信してしまうような脆弱性を、ごく稀に耳にする。

  • 複数の人に聞いたが、これ自体には明確な名前がついていない。Googleのドキュメントに警告が書かれていたりはする。

  • https://developers.google.com/identity/sign-in/web/backend-auth

  • 「任意のユーザーIDをサーバーに送信してユーザーを偽装できるので、ユーザーIDそのものをバックエンドサーバーに送って認証に使うな、代わりに検証可能なID tokenを使え」という注意書きがある。

ID ProviderがPPIDを発行している場合、たまたま攻撃が不可能になるようなケースも有りうる。ただし、useridが秘密の文字列として保たれるかどうかは連携するサービスの仕様次第で、URLに露出したり、他のユーザーのuseridが確認できるようなケースも発生しうる。

そのため「userid のみを送信して認証とみなすのはどんな場合でも推奨されない」

まとめ

大事なことなので5回ぐらい書いておく。

  • 「userid のみを送信して認証とみなすのはどんな場合でも推奨されない」
  • 「userid のみを送信して認証とみなすのはどんな場合でも推奨されない」
  • 「userid のみを送信して認証とみなすのはどんな場合でも推奨されない」
  • 「userid のみを送信して認証とみなすのはどんな場合でも推奨されない」
  • 「userid のみを送信して認証とみなすのはどんな場合でも推奨されない」
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.